52792 - Tru64 5.0 crashes at startup

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[jim_nance]

Using a Sept 15 pull and building under Tru64 5.0:

bash-2.04$ env LD_LIBRARY_PATH=.:/house/jnance/mbuild/prefix/lib ladebug
./mozilla-bin 
Welcome to the Ladebug Debugger Version 4.0-62 (built Jun 23 2000)
------------------ 
object file name: ./mozilla-bin 
Reading symbolic information ...done
(ladebug) r
Warning: MOZILLA_FIVE_HOME not set.
RegSelf Shift_JIS to Unicode converter complete
RegSelf EUC-JP to Unicode converter complete
RegSelf ISO-2022-JP to Unicode converter complete
RegSelf Unicode to Shift_JIS converter complete
RegSelf Unicode to EUC-JP converter complete
RegSelf Unicode to ISO-2022-JP converter complete
RegSelf Unicode to jis_0201 converter complete
RegSelf Unicode to jis_0208-1983 converter complete
RegSelf Unicode to jis_0212-1990 converter complete
RegSelf Unicode to Big5 converter complete
RegSelf Unicode to x-x-big5 converter complete
RegSelf Big5 to Unicode converter complete
Thread received signal SEGV
stopped at [JSGCThing* gc_new_arena(JSArenaPool*):195 0x3ffbffbd9d4]
    195         pi->flags = flagp;
(ladebug) where 5
>0  0x3ffbffbd9d4 in gc_new_arena(pool=Info: symbol pool is defined but not
allocated (optimized away)
<no value>) "/var/tmp/jnance/mozilla/js/src/jsgc.c":195
#1  0x3ffbffbde58 in js_AllocGCThing(cx=Info: symbol cx is defined but not
allocated (optimized away)
<no value>, flags=Info: symbol flags is defined but not allocated (optimized
away)
<no value>) "/var/tmp/jnance/mozilla/js/src/jsgc.c":407
#2  0x3ffbfff7ed8 in js_NewString(cx=Info: symbol cx is defined but not
allocated (optimized away)
<no value>, chars=Info: symbol chars is defined but not allocated (optimized
away)
<no value>, length=Info: symbol length is defined but not allocated (optimized a

Comment 1

[jim_nance]

I did a little more debugging.  The problem is in the javascript garbage
collector.  Its not 64 bit clean.  One problem was that GC_PAGE_MASK is
a 32 bit integer, so when we take a pointer and and it with ~GC_PAGE_MASK
we erase the upper 32 bits of the pointer.  I made GC_PAGE_MASK a uint8
and it gets further but then dies in gc_find_flags:
    214     if (flagp >= pi->split)
(ladebug) p flagp
0x1

I dont know how to debug this.

I suspect this problem will not only affect the alpha, but also any of the
other 64 bit machines.

Comment 2

[jim_nance]

blame says this is brendan's code so I am reassigning

Comment 3

[Brendan Eich [:brendan]]

Dammit, my days hacking 64-bit code at SGI and MicroUnity are long gone.  Sorry 
about that.  I'll come up with a patch.

/be

Comment 4

[Brendan Eich [:brendan]]

One simple fix:

#define GC_PAGE_MASK    ((jsuword) JS_BITMASK(GC_PAGE_SHIFT))

instead of the uncast JS_BITMASK(GC_PAGE_SHIFT), which makes a JSUint32, should 
help.  Maybe it's enough to fix things?  Please let me know.

/be

Comment 5

[Doron Rosenberg (IBM)]

setting default qa

Comment 6

[jim_nance]

Actually something like this was the first thing I tried.  It does get further
than with out this cast.  It still crashes though.  The stack trace that I
initially included was with this cast in place.

Comment 7

[jim_nance]

It looks like this bug is gone!!

Comment 8

[Brendan Eich [:brendan]]

jsuword is requird (you wrote "I made GC_PAGE_MASK a uint8" but that goes in the 
wrong direction -- even fewer bits!).  Maybe that was the trick.  I certainly 
can't find any 64-bit impurities by inspection now.  I won't blunder this way 
again, I promise!  Thanks again, and for the testdrive.compaq.com pointer.

Can someone verify, or should Jim self-verify?

/be

Comment 9

[Phil Schwartau]

I don't have this OS on any machine. Jim, would you be able to check things
with a current pull, and mark this bug Verified or reopen it as necessary? 

(Or anyone else with this OS - thanks)