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: