Closed Bug 351261 Opened 18 years ago Closed 18 years ago

startup crash. [@ js_XDRStringAtom] / jsxdrapi.c

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
SGI
IRIX
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: g.fischer, Unassigned)

Details

(Keywords: crash)

Crash Data

Attachments

(1 obsolete file)

User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP27; en-US; rv:1.9a1) Gecko/R-A-C SeaMonkey/1.5a Build Identifier: irix 6.5.30, mipspro 7.4.4, firefox 2.0b2. ------------------------------------------ direct startup crash. gtk1 and gtk2. debugger says: Process 561566: Thread 0x10000: Stopped on signal SIGBUS: Bus error (default) js_XDRStringAtom(0x10182e08, 0x0, 0x10182e08, 0x0, 0x44bc000, 0x10182e08, 0x100c38d0, 0x0) ["jsxdrapi.c":677, 0x004cc16c] and the related code part: JS_ARENA_RELEASE(&cx->tempPool, mark); thanks Reproducible: Always
Version: unspecified → 2.0 Branch
Assignee: nobody → general
Component: General → JavaScript Engine
Keywords: crash
Product: Firefox → Core
QA Contact: general → general
Summary: startup crash. js_XDRStringAtom / jsxdrapi.c → startup crash. [@ js_XDRStringAtom] / jsxdrapi.c
Version: 2.0 Branch → 1.8 Branch
Try removing your .mfasl files and restarting. Have you been running with the same profile using trunk and 1.8 branch (Minefield and Bonecho) builds? If so, this is probably a dup of bug 350787. If not, could this bug be peculiar to MIPS? Long time since I had an SGI box (I was there from '85-'92). /be
(In reply to comment #1) > Try removing your .mfasl files and restarting. Have you been running with the > same profile using trunk and 1.8 branch (Minefield and Bonecho) builds? If so, > this is probably a dup of bug 350787. no, always testing with a new profile. > > If not, could this bug be peculiar to MIPS? no clue. how should i know? > Long time since I had an SGI box > (I was there from '85-'92). nice :-) > > /be >
still present in 2.0rc1. this time: Core from signal SIGBUS: Bus error js_XDRStringAtom(0x101b2b70, 0x0, 0x101b2b70, 0x0, 0x44bc000, 0x101b2b70, 0x100b6390, 0x0) ["jsxdrapi.c":677, 0x004d032c] same code line ref.
had a look into jsxdrapi.c and noticed that the block my debugger complains about has a notice about bug #321985. looking at that shows some more or less significant rewrites. however what i don't understand is that these changes are from 2006-02-14 but i was able to build and run 2.0a3 without any issues although it came out in late may! so why wasn't the 2.0a3 affected although having the same code?
same for rc2: Core from signal SIGBUS: Bus error js_XDRStringAtom(0x101b2b70, 0x0, 0x101b2b70, 0x0, 0x44bc000, 0x101b2b70, 0x101b2b70, 0x1010df38) ["jsxdrapi.c":677, 0x004e05ec]
(In reply to comment #4) > so why wasn't the 2.0a3 affected although having the same code? Note that the crash happens inside JS_ARENA_RELEASE macro. That code is affected by changes from bug 347645 whuch was committed to the branch on 2006-08-08 and iirc later then 2.0a3. I suspect that xdr code did in fact reused the cached arena left from earlier decompilations. That arena may have "better" placement in heap that hided the problem. Could you check in the debugger what is the value of nchars?
A question about IRIX. That error, "Stopped on signal SIGBUS: Bus error (default)", just means that invalid memory was referenced? Or can it also mean an alignment violations?
Misalignment => SIGBUS (MIPS is RISC), bad address => SIGSEGV. Can anyone spot the misalignment? /be
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #6) > (In reply to comment #4) > > so why wasn't the 2.0a3 affected although having the same code? > > Note that the crash happens inside JS_ARENA_RELEASE macro. That code is > affected by changes from bug 347645 whuch was committed to the branch on > 2006-08-08 and iirc later then 2.0a3. > > I suspect that xdr code did in fact reused the cached arena left from earlier > decompilations. That arena may have "better" placement in heap that hided the > problem. > > Could you check in the debugger what is the value of nchars? > ah, thanks for looking after this! meanwhile it's quite hard to get someone for non win/lin/mac issues. i'm not very good at debugging but will try to find it ...
(In reply to comment #9) > i'm not very good at debugging but will try to find it ... And if you can the debugger into js_XDRStringAtom, can you check the value of cx->tempPool.mask. It must be 3 meaning that all allocations must be aligned on 1 << 3 == 8 bytes. And another question, the browser is compiled with GCC, right?
(In reply to comment #10) > (In reply to comment #9) > > i'm not very good at debugging but will try to find it ... > > And if you can the debugger into js_XDRStringAtom, can you check the value of > cx->tempPool.mask. It must be 3 meaning that all allocations must be aligned on > 1 << 3 == 8 bytes. No, it's a mask, so it means 0 mod 4 alignment -- that is, the arena pool will always return allocation address p such that (p & 3) == 0. /be
(In reply to comment #11) > > cx->tempPool.mask. It must be 3 meaning that all allocations must be aligned on > > 1 << 3 == 8 bytes. > > No, it's a mask, so it means 0 mod 4 alignment -- that is, the arena pool will > always return allocation address p such that (p & 3) == 0. Right, it must be 7, (1 << 3) - 1, since js_NewContext initializes the pool with the requirement to align everything on sizeof(jsdouble) bytes.
Ok, 7 -- so 0 mod 8. Should have remembered. Just wanted to point out that it was not the log2(alignment), rather alignment-1, that's stored in the mask field. /be
(In reply to comment #10) > > And another question, the browser is compiled with GCC, right? > no, never. always mipspro as i wrote in the opening post.
(In reply to comment #13) > Ok, 7 -- so 0 mod 8. Should have remembered. Just wanted to point out that it > was not the log2(alignment), rather alignment-1, that's stored in the mask > field. > > /be > okay, working on it. btw i have access to gdb as well so if you have a hint to get the values you need quickly with that be my guest :-)
What does 'info regs' say in gdb? There might be a badvaddr or some such register, or we should be able to spot the bad pointer by looking at the current instruction via x/i $pc (so show that too). /be
here we go: (gdb) r Starting program: /mnt/3/temp/bin/firefox-bin Program received signal ?, Unknown signal. 0x05f961c0 in ?? () (gdb) info registers zero at v0 v1 R0 0000000000000000 0000000000129fac 0000000000000007 0000000000000000 a0 a1 a2 a3 R4 0000000010045b20 0000000010115a00 000000001010e978 000000000417ddd0 a4 a5 a6 a7 R8 0000000005fd1730 0000000000000001 0000000000000000 0000000000000016 t0 t1 t2 t3 R12 0000000000000001 0000000000000000 0000000000000000 73746f72792d696e s0 s1 s2 s3 R16 0000000005fd1730 0000000005fd1734 0000000000000010 ffffffff80000000 s4 s5 s6 s7 R20 0000000010116348 0000000010045b20 0000000010115a00 000000001010e978 t8 t9 k0 k1 R24 00000000000008f8 0000000005f961c0 0000000000000000 00003f000002fcb0 gp sp s8 ra R28 00000000041b22ac 000000007ffe6f60 000000000417ddd0 0000000004094c2c pc cause bad hi 0000000005f961c0 0000000000000008 0000000000000000 0000000000000000 lo fsr fir 0000000000000000 00000000 00000000 (gdb) i $pc Undefined info command: "$pc". Try "help info". (gdb) x $pc 0x5f961c0: 0x3c010005
I said "x/i $pc", not "i $pc" or "x $pc" -- in gdb x/i is short for examine instruction at. Need to see the faulting instruction decoded (my MIPS book is in a box somewhere ;-). /be
(In reply to comment #18) > I said "x/i $pc", not "i $pc" or "x $pc" -- in gdb x/i is short for examine > instruction at. Need to see the faulting instruction decoded (my MIPS book is > in a box somewhere ;-). > > /be > ah sorry got that wrong. anyway here it is: (gdb) x/i $pc 0x5f961c0: lui at,0x5
Hmm, pc must be off by one. Try x/i $pc - 4 and also x/10i $pc-16 (for good measure). Thanks, /be
(In reply to comment #20) > Hmm, pc must be off by one. Try x/i $pc - 4 and also x/10i $pc-16 (for good > measure). Thanks, > > /be > i have to thank! here it is: (gdb) x/i $pc - 4 0x5f961bc: nop (gdb) x/10i $pc-16 0x5f961b0: nop 0x5f961b4: nop 0x5f961b8: nop 0x5f961bc: nop 0x5f961c0: lui at,0x5 0x5f961c4: addiu at,at,31184 0x5f961c8: addiu sp,sp,-96 0x5f961cc: sd gp,80(sp) 0x5f961d0: addu gp,t9,at 0x5f961d4: lw t9,-29680(gp)
just wanna let you know that it also occured using ff 2.0
As you are compiling with MIPSPro, this could be a duplicate of bug 79562. Try rebuilding with --disable-optimize.
Simple fix; just need to add jsxdrapi.o to the -O1 exception list for MIPSpro; hint was bug #79562. --- js/src/Makefile.in.save Thu Jul 27 15:56:20 2006 +++ js/src/Makefile.in Tue Nov 28 00:39:32 2006 @@ -297,7 +297,7 @@ ifeq ($(OS_ARCH),IRIX) ifndef GNU_CC _COMPILE_CFLAGS = $(patsubst -O%,-O1,$(COMPILE_CFLAGS)) -jsapi.o jsarena.o jsarray.o jsatom.o jsemit.o jsfun.o jsinterp.o jsregexp.o jsparse.o jsopcode.o jsscript.o: %.o: %.c Makefile.in +jsapi.o jsxdrapi.o jsarena.o jsarray.o jsatom.o jsemit.o jsfun.o jsinterp.o jsregexp.o jsparse.o jsopcode.o jsscript.o: %.o: %.c Makefile.in $(REPORT_BUILD) @$(MAKE_DEPS_AUTO) $(CC) -o $@ -c $(_COMPILE_CFLAGS) $< endif
great! anyhow the patch generated an error message here and wasn't applied. i attached a 'clean' one ...
Attached patch include jsxdrapi.o in -O1 group (obsolete) — — Splinter Review
Comment on attachment 246802 [details] [diff] [review] include jsxdrapi.o in -O1 group attaching patches is much better than inlining them, thanks. but better still is using cvs diff.
Attachment #246802 - Flags: review?(brendan)
Attachment #246802 - Flags: review?(brendan) → review+
Comment on attachment 246802 [details] [diff] [review] include jsxdrapi.o in -O1 group mozilla/js/src/Makefile.in 3.108
Attachment #246802 - Attachment is obsolete: true
if you need this on a branch, ask (order: 1.8?, 1.8.0?)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Version: 1.8 Branch → Trunk
Flags: in-testsuite-
is bug 79562 gone now that this is fixed? dupe?
Crash Signature: [@ js_XDRStringAtom]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: