14805 - Mozilla segfaults on startup with an optimized build

Status: VERIFIED DUPLICATE of bug 16612

(Core :: JavaScript Engine, defect, P1)

Description

[Daniel Roberts]

When I compile with optimizations enabled, Mozilla segfaults on startup.  Here
is the backtrace from gdb:

#0  0x41213d60 in ?? ()
#1  0x403298c6 in WrappedNative_GetProperty (cx=0x40ffc700, obj=0x40f749c8,
    id=135127528, vp=0xbffff330) at xpcwrappednativejsops.cpp:219
#2  0x4007499f in js_Interpret (cx=0x40ffc700, result=0xbffff4b8)
    at jsinterp.c:2188
#3  0x4006eb71 in js_Execute (cx=0x40ffc700, chain=0x40f73db8,
    script=0x41467858, fun=0x0, down=0x0, debugging=0, result=0xbffff4b8)
    at jsinterp.c:828
#4  0x4005434b in JS_EvaluateUCScriptForPrincipals (cx=0x40ffc700,
    obj=0x40f73db8, principals=0x81c11f8, chars=0x41869530, length=10156,
    filename=0x40fa79a0 "chrome://sidebar/content/sidebarOverlay.js",
    lineno=0, rval=0xbffff4b8) at jsapi.c:2619
#5  0x403a14a5 in nsJSContext::EvaluateString (this=0x40ffc6d8,
    aScript=@0x40f97d30, jsObj=0x40f73db8, principal=0x0,
    aURL=0x40fa79a0 "chrome://sidebar/content/sidebarOverlay.js", aLineNo=0,
    aRetValue=@0xbffff5e8, aIsUndefined=0xbffff5e0) at nsJSEnvironment.cpp:186
#6  0x403a104f in nsJSContext::EvaluateString (this=0x40ffc6d8,
    aScript=@0x40f97d30,
    aURL=0x40fa79a0 "chrome://sidebar/content/sidebarOverlay.js", aLineNo=0,
    aRetValue=@0xbffff5e8, aIsUndefined=0xbffff5e0) at nsJSEnvironment.cpp:132
#7  0x40847780 in XULContentSinkImpl::EvaluateScript (this=0x40f96300,
    aScript=@0x40f97d30, aURI=0x416a0d08, aLineNo=0)
    at nsXULContentSink.cpp:1650
#8  0x408475e1 in XULContentSinkImpl::DoneLoadingScript (aLoader=0x40fa1108,
    aData=@0x40f97d30, aRef=0x40f96300, aStatus=0) at nsXULContentSink.cpp:1605
#9  0x40848a20 in nsUnicharStreamLoader::OnStopRequest (this=0x40fa1108,
    channel=0x41673a40, ctxt=0x0, status=0, errorMsg=0x0)
    at nsNetStreamLoader.cpp:159
#10 0x408ded23 in nsChannelListener::OnStopRequest (this=0x40fbcea8,
    aChannel=0x41673a40, aContext=0x0, aStatus=0, aMsg=0x0)
    at nsDocLoader.cpp:1590
#11 0x40952cff in nsFileChannel::OnStopRequest (this=0x41673a40,
    transportChannel=0x40fbd0a8, context=0x0, aStatus=0, aMsg=0x0)
    at nsFileChannel.cpp:466
#12 0x40878f2f in nsOnStopRequestEvent::HandleEvent (this=0x81e14c0)
    at nsAsyncStreamListener.cpp:282
#13 0x4087899f in nsStreamListenerEvent::HandlePLEvent (aEvent=0x81e14e0)
    at nsAsyncStreamListener.cpp:152
#14 0x4015a391 in PL_HandleEvent (self=0x81e14e0) at plevent.c:541
#15 0x4015a290 in PL_ProcessPendingEvents (self=0x8108a28) at plevent.c:475
#16 0x4011c5e2 in nsEventQueueImpl::ProcessPendingEvents (this=0x81089f8)
    at nsEventQueue.cpp:118
#17 0x4049ff11 in event_processor_callback (data=0x81089f8, source=7,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:153
#18 0x40681d7b in gdk_io_invoke ()
#19 0x406ac3ca in g_io_unix_dispatch ()
#20 0x406ada86 in g_main_dispatch ()
#21 0x406ae041 in g_main_iterate ()
#22 0x406ae1e1 in g_main_run ()
#23 0x405da7a9 in gtk_main ()
#24 0x404a0592 in nsAppShell::Run (this=0x8109730) at nsAppShell.cpp:379
#25 0x4035da14 in nsAppShellService::Run (this=0x8108758)
    at nsAppShellService.cpp:461
#26 0x804a9bc in main1 (argc=1, argv=0xbffffbc4) at nsAppRunner.cpp:591
#27 0x804ac29 in main (argc=1, argv=0xbffffbc4) at nsAppRunner.cpp:702
#28 0x40212cb3 in __libc_start_main (main=0x804aaec <main>, argc=1,
    argv=0xbffffbc4, init=0x80495c4 <_init>, fini=0x804cc34 <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffbbc)
    at ../sysdeps/generic/libc-start.c:78

Comment 1

[Daniel Roberts]

Forgot to mention that this was compiled with GCC 2.95.1 on a Red Hat 6.0 system
with glibc 2.1.

Comment 2

[Mike McCabe]

John, could you look at this (and possibly reassign?)

XPConnect wins the prize as being at the top of the stack...

Comment 3

[John Bandhauer]

This bug is two weeks old. Is it still doing this? I don't have an optimized
Linux build handy. I'd expect this to be a pretty common complaint by now if
this were common.

Comment 4

[Daniel Roberts]

Nope.  The bug still exists--using an optimized CVS build done on October 11,
built with GCC 2.95.1, I still get:

Program received signal SIGSEGV, Segmentation fault.
0x0 in ?? ()
Current language:  auto; currently c
(gdb) bt
#0  0x0 in ?? ()
#1  0x41021b7c in nsXPCWrappedNativeClass::CallWrappedMethod (this=0x82ace70,
    cx=0x82987b0, wrapper=0x82acf58, desc=0x82acec8, callMode=CALL_GETTER,
    argc=0, argv=0x0, vp=0xbffff330) at ../../../../dist/include/xptinfo.h:116
#2  0x41023506 in WrappedNative_GetProperty (cx=0x82987b0, obj=0x829cce8,
    id=136803472, vp=0xbffff330)
    at ../../../../../mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:235

etc...

Comment 5

[John Bandhauer]

This is likely a dup of 16318 (or at least associated).

Comment 6

[cls]

*** This bug has been marked as a duplicate of 16612 ***

Comment 7

[leger]

Yes.  Marking Verified/Dup