Closed Bug 608526 Opened 14 years ago Closed 5 months ago

crash: Assertion failure: thread->data.nativeStackBase == GetNativeStackBase(), at js/src/jscntxt.cpp:645

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: bjacob, Unassigned)

References

Details

(Whiteboard: [approved-patches-landed] not-ready)

Attachments

(6 files, 4 obsolete files)

Steps to reproduce:

dist/bin/firefox http://audioscene.org/scene-files/humph/VideoShaderSandbox/video_shader_sandbox.html

Backtrace:

#0  0x000000385bea6a6d in nanosleep () from /lib64/libc.so.6
#1  0x000000385bea68e0 in sleep () from /lib64/libc.so.6
#2  0x00007fd2b27f8be8 in ah_crap_handler (signum=6) at /home/bjacob/mozilla-central/toolkit/xre/nsSigHandlers.cpp:132
#3  0x00007fd2b27fd422 in nsProfileLock::FatalSignalHandler (signo=6, info=0x7fffdd9b0bb0, context=0x7fffdd9b0a80) at nsProfileLock.cpp:221
#4  <signal handler called>
#5  0x000000385ca0f30b in raise () from /lib64/libpthread.so.0
#6  0x00007fd2b41bf308 in JS_Assert (s=0x7fd2b4a08310 "thread->data.nativeStackBase == GetNativeStackBase()", file=0x7fd2b4a08000 "/home/bjacob/mozilla-central/js/src/jscntxt.cpp", ln=651)
    at /home/bjacob/mozilla-central/js/src/jsutil.cpp:83
#7  0x00007fd2b4090113 in js_CurrentThread (rt=0x1c8dd20) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:651
#8  0x00007fd2b409013a in js_InitContextThread (cx=0x3835380) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:659
#9  0x00007fd2b409069e in js_NewContext (rt=0x1c8dd20, stackChunkSize=8192) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:796
#10 0x00007fd2b40532ac in JS_NewContext (rt=0x1c8dd20, stackChunkSize=8192) at /home/bjacob/mozilla-central/js/src/jsapi.cpp:967
#11 0x00007fd2b31251ce in nsJSContext::nsJSContext (this=0x389afc0, aRuntime=0x1c8dd20) at /home/bjacob/mozilla-central/dom/base/nsJSEnvironment.cpp:1307
#12 0x00007fd2b312ca37 in nsJSRuntime::CreateContext (this=0x1d08ee0, aContext=0x7fffdd9b10f0) at /home/bjacob/mozilla-central/dom/base/nsJSEnvironment.cpp:3884
#13 0x00007fd2b30c87e2 in nsXBLDocGlobalObject::EnsureScriptEnvironment (this=0x38b2180, aLangID=2) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLDocumentInfo.cpp:317
#14 0x00007fd2b30c8ac8 in nsXBLDocGlobalObject::GetContext (this=0x38b2180) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLDocumentInfo.cpp:351
#15 0x00007fd2b30d18d5 in nsXBLProtoImpl::CompilePrototypeMembers (this=0x38acf70, aBinding=0x389ac10) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLProtoImpl.cpp:165
#16 0x00007fd2b30d15cd in nsXBLProtoImpl::InitTargetObjects (this=0x38acf70, aBinding=0x389ac10, aContext=0x290e610, aBoundElement=0x3859df0, aScriptObjectHolder=0x7fffdd9b1360, 
    aTargetClassObject=0x7fffdd9b1358) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLProtoImpl.cpp:111
#17 0x00007fd2b30d13c9 in nsXBLProtoImpl::InstallImplementation (this=0x38acf70, aBinding=0x389ac10, aBoundElement=0x3859df0)
    at /home/bjacob/mozilla-central/content/xbl/src/nsXBLProtoImpl.cpp:79
#18 0x00007fd2b30c21b6 in nsXBLPrototypeBinding::InstallImplementation (this=0x389ac10, aBoundElement=0x3859df0) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLPrototypeBinding.cpp:539
#19 0x00007fd2b30bd9d7 in nsXBLBinding::InstallImplementation (this=0x37b4750) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLBinding.cpp:940
#20 0x00007fd2b30dada4 in nsXBLService::LoadBindings (this=0x234f670, aContent=0x3859df0, aURL=0x23a7b20, aOriginPrincipal=0x1cfa4e0, aAugmentFlag=0, aBinding=0x37ccdb0, aResolveStyle=
    0x7fffdd9b16dc) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLService.cpp:647
#21 0x00007fd2b2a9237e in nsCSSFrameConstructor::AddFrameConstructionItemsInternal (this=0x359c2b0, aState=..., aContent=0x3859df0, aParentFrame=0x3557b00, aTag=0x1c82300, aNameSpaceID=9, 
    aSuppressWhiteSpaceOptimizations=1, aStyleContext=0x3557e28, aFlags=3, aItems=...) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5126
#22 0x00007fd2b2a920f8 in nsCSSFrameConstructor::AddFrameConstructionItems (this=0x359c2b0, aState=..., aContent=0x3859df0, aSuppressWhiteSpaceOptimizations=1, aParentFrame=0x3557b00, 
    aItems=...) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5066
#23 0x00007fd2b2a9ce23 in nsCSSFrameConstructor::ProcessChildren (this=0x359c2b0, aState=..., aContent=0x37cd6b0, aStyleContext=0x37896a8, aFrame=0x3557b00, aCanHaveGeneratedContent=1, 
    aFrameItems=..., aAllowBlockStyles=0, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9545
#24 0x00007fd2b2a8fb0e in nsCSSFrameConstructor::ConstructFrameFromItemInternal (this=0x359c2b0, aItem=..., aState=..., aParentFrame=0x37893c8, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:3818
#25 0x00007fd2b2a93231 in nsCSSFrameConstructor::ConstructFramesFromItem (this=0x359c2b0, aState=..., aIter=..., aParentFrame=0x37893c8, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5481
#26 0x00007fd2b2aa6817 in nsCSSFrameConstructor::ConstructFramesFromItemList (this=0x359c2b0, aState=..., aItems=..., aParentFrame=0x37893c8, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9475
#27 0x00007fd2b2a9d084 in nsCSSFrameConstructor::ProcessChildren (this=0x359c2b0, aState=..., aContent=0x359ce80, aStyleContext=0x3788e48, aFrame=0x37893c8, aCanHaveGeneratedContent=1, 
    aFrameItems=..., aAllowBlockStyles=1, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9591
#28 0x00007fd2b2a9f788 in nsCSSFrameConstructor::ConstructBlock (this=0x359c2b0, aState=..., aDisplay=0x3789120, aContent=0x359ce80, aParentFrame=0x3788fe0, aContentParentFrame=0x3788fe0, 
    aStyleContext=0x3788e48, aNewFrame=0x7fffdd9b21e0, aFrameItems=..., aAbsPosContainer=0, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:10641
#29 0x00007fd2b2a91069 in nsCSSFrameConstructor::ConstructNonScrollableBlock (this=0x359c2b0, aState=..., aItem=..., aParentFrame=0x3788fe0, aDisplay=0x3789120, aFrameItems=..., aNewFrame=
    0x7fffdd9b21e0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:4531
#30 0x00007fd2b2a8f64b in nsCSSFrameConstructor::ConstructFrameFromItemInternal (this=0x359c2b0, aItem=..., aState=..., aParentFrame=0x3788fe0, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:3728
#31 0x00007fd2b2a93231 in nsCSSFrameConstructor::ConstructFramesFromItem (this=0x359c2b0, aState=..., aIter=..., aParentFrame=0x3788fe0, aFrameItems=...)
---Type <return> to continue, or q <return> to quit---
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5481
#32 0x00007fd2b2aa6817 in nsCSSFrameConstructor::ConstructFramesFromItemList (this=0x359c2b0, aState=..., aItems=..., aParentFrame=0x3788fe0, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9475
#33 0x00007fd2b2a9611f in nsCSSFrameConstructor::ContentAppended (this=0x359c2b0, aContainer=0x3688450, aFirstNewContent=0x359ce00, aAllowLazyConstruction=0)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6661
#34 0x00007fd2b2a9547d in nsCSSFrameConstructor::CreateNeededFrames (this=0x359c2b0, aContent=0x3688450) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6328
#35 0x00007fd2b2a954eb in nsCSSFrameConstructor::CreateNeededFrames (this=0x359c2b0, aContent=0x35fa560) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6338
#36 0x00007fd2b2a95608 in nsCSSFrameConstructor::CreateNeededFrames (this=0x359c2b0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6353
#37 0x00007fd2b2b185e4 in PresShell::FlushPendingNotifications (this=0x3561640, aType=Flush_Style) at /home/bjacob/mozilla-central/layout/base/nsPresShell.cpp:4848
#38 0x00007fd2b2b31187 in nsRefreshDriver::Notify (this=0x35a47c0) at /home/bjacob/mozilla-central/layout/base/nsRefreshDriver.cpp:299
#39 0x00007fd2b3eb039d in nsTimerImpl::Fire (this=0x3720b90) at /home/bjacob/mozilla-central/xpcom/threads/nsTimerImpl.cpp:428
#40 0x00007fd2b3eb062d in nsTimerEvent::Run (this=0x7fd298000f20) at /home/bjacob/mozilla-central/xpcom/threads/nsTimerImpl.cpp:517
#41 0x00007fd2b3ea90f9 in nsThread::ProcessNextEvent (this=0x1a594a0, mayWait=1, result=0x7fffdd9b2acc) at /home/bjacob/mozilla-central/xpcom/threads/nsThread.cpp:609
#42 0x00007fd2b3e34b8c in NS_ProcessNextEvent_P (thread=0x1a594a0, mayWait=1) at nsThreadUtils.cpp:250
#43 0x00007fd2b3ca3b89 in mozilla::ipc::MessagePump::Run (this=0x1a6acd0, aDelegate=0x1a59160) at /home/bjacob/mozilla-central/ipc/glue/MessagePump.cpp:134
#44 0x00007fd2b3f0f81f in MessageLoop::RunInternal (this=0x1a59160) at /home/bjacob/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#45 0x00007fd2b3f0f7a4 in MessageLoop::RunHandler (this=0x1a59160) at /home/bjacob/mozilla-central/ipc/chromium/src/base/message_loop.cc:202
#46 0x00007fd2b3f0f735 in MessageLoop::Run (this=0x1a59160) at /home/bjacob/mozilla-central/ipc/chromium/src/base/message_loop.cc:176
#47 0x00007fd2b3b46e7b in nsBaseAppShell::Run (this=0x1d3f180) at /home/bjacob/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:181
#48 0x00007fd2b3898801 in nsAppStartup::Run (this=0x1e4d870) at /home/bjacob/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:191
#49 0x00007fd2b27ea787 in XRE_main (argc=5, argv=0x7fffdd9b3728, aAppData=0x19f4cc0) at /home/bjacob/mozilla-central/toolkit/xre/nsAppRunner.cpp:3682
#50 0x000000000040121f in main (argc=5, argv=0x7fffdd9b3728) at /home/bjacob/mozilla-central/browser/app/nsBrowserApp.cpp:158
Benoit, do you have the Java plugin installed? See bug 607146 (thanks to sayrer for pointing it out -- dup if you can).

/be
I don't have the Java plugin installed according to about:plugins.

I have created a new profile, and I now get this crash only on exit, i.e. the page loads and plays normally, but I get the same assertion failure when I close firefox. The stack trace is different though (see below). I'm not competent to decide if this is the same as bug 607146, but if it is, then that means that 607146 is not java-related.

#0  0x000000385bea6a6d in nanosleep () from /lib64/libc.so.6
#1  0x000000385bea68e0 in sleep () from /lib64/libc.so.6
#2  0x00007fa27e8bdbe8 in ah_crap_handler (signum=6) at /home/bjacob/mozilla-central/toolkit/xre/nsSigHandlers.cpp:132
#3  0x00007fa27e8c2422 in nsProfileLock::FatalSignalHandler (signo=6, info=0x7fff2e39bff0, context=0x7fff2e39bec0) at nsProfileLock.cpp:221
#4  <signal handler called>
#5  0x000000385ca0f30b in raise () from /lib64/libpthread.so.0
#6  0x00007fa280284308 in JS_Assert (s=0x7fa280acd310 "thread->data.nativeStackBase == GetNativeStackBase()", file=0x7fa280acd000 "/home/bjacob/mozilla-central/js/src/jscntxt.cpp", ln=651)
    at /home/bjacob/mozilla-central/js/src/jsutil.cpp:83
#7  0x00007fa280155113 in js_CurrentThread (rt=0x2400970) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:651
#8  0x00007fa28015513a in js_InitContextThread (cx=0x31f8650) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:659
#9  0x00007fa28015569e in js_NewContext (rt=0x2400970, stackChunkSize=8192) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:796
#10 0x00007fa2801182ac in JS_NewContext (rt=0x2400970, stackChunkSize=8192) at /home/bjacob/mozilla-central/js/src/jsapi.cpp:967
#11 0x00007fa27f76cbf9 in XPCJSContextStack::GetSafeJSContext (this=0x242fae0, aSafeJSContext=0x7fff2e39c6a8) at /home/bjacob/mozilla-central/js/src/xpconnect/src/xpcthreadcontext.cpp:259
#12 0x00007fa27f73abcb in XPCCallContext::Init (this=0x7fff2e39c680, callerLanguage=XPCContext::LANG_NATIVE, callBeginRequest=1, obj=0x0, funobj=0x0, getWrappedNative=1, name=..., argc=
    4294967295, argv=0x0, rval=0x0) at /home/bjacob/mozilla-central/js/src/xpconnect/src/xpccallcontext.cpp:145
#13 0x00007fa27f73a936 in XPCCallContext::XPCCallContext (this=0x7fff2e39c680, callerLanguage=XPCContext::LANG_NATIVE, cx=0x0, obj=0x0, funobj=0x0, name=..., argc=4294967295, argv=0x0, rval=
    0x0) at /home/bjacob/mozilla-central/js/src/xpconnect/src/xpccallcontext.cpp:64
#14 0x00007fa27f776c69 in GetContextFromObject (obj=0x7fa2583f2410) at /home/bjacob/mozilla-central/js/src/xpconnect/src/xpcwrappedjsclass.cpp:555
#15 0x00007fa27f777376 in nsXPCWrappedJSClass::DelegatedQueryInterface (this=0x263b120, self=0x4544890, aIID=..., aInstancePtr=0x7fff2e39caf8)
    at /home/bjacob/mozilla-central/js/src/xpconnect/src/xpcwrappedjsclass.cpp:688
#16 0x00007fa27f76f9f9 in nsXPCWrappedJS::QueryInterface (this=0x4544890, aIID=..., aInstancePtr=0x7fff2e39caf8) at /home/bjacob/mozilla-central/js/src/xpconnect/src/xpcwrappedjs.cpp:186
#17 0x00007fa27fef42fa in nsWeakReference::QueryReferent (this=0x43cb810, aIID=..., aInstancePtr=0x7fff2e39caf8) at nsWeakReference.cpp:151
#18 0x00007fa27fef3e0c in nsQueryReferent::operator() (this=0x7fff2e39cb70, aIID=..., answer=0x7fff2e39caf8) at nsWeakReference.cpp:88
#19 0x00007fa27e8b43a7 in nsCOMPtr<nsIObserver>::assign_from_helper (this=0x7fff2e39cb50, helper=..., aIID=...) at ../../dist/include/nsCOMPtr.h:1272
#20 0x00007fa27e8b29be in nsCOMPtr<nsIObserver>::nsCOMPtr (this=0x7fff2e39cb50, helper=...) at ../../dist/include/nsCOMPtr.h:644
#21 0x00007fa27ff1c5b3 in nsObserverList::FillObserverArray (this=0x44eaee0, aArray=...) at /home/bjacob/mozilla-central/xpcom/ds/nsObserverList.cpp:106
#22 0x00007fa27ff1c6b0 in nsObserverList::NotifyObservers (this=0x44eaee0, aSubject=0x0, aTopic=0x7fa280989659 "places-shutdown", someData=0x0)
    at /home/bjacob/mozilla-central/xpcom/ds/nsObserverList.cpp:127
#23 0x00007fa27ff1e19e in nsObserverService::NotifyObservers (this=0x23504c0, aSubject=0x0, aTopic=0x7fa280989659 "places-shutdown", someData=0x0)
    at /home/bjacob/mozilla-central/xpcom/ds/nsObserverService.cpp:182
#24 0x00007fa27fb44b5c in nsNavHistory::Observe (this=0x2b77c00, aSubject=0x21e5ce0, aTopic=0x7fa2805f999f "profile-change-teardown", aData=0x7fa2805f9b80)
    at /home/bjacob/mozilla-central/toolkit/components/places/src/nsNavHistory.cpp:5821
#25 0x00007fa27ff1c6e9 in nsObserverList::NotifyObservers (this=0x44e9ef0, aSubject=0x21e5ce0, aTopic=0x7fa2805f999f "profile-change-teardown", someData=0x7fa2805f9b80)
    at /home/bjacob/mozilla-central/xpcom/ds/nsObserverList.cpp:130
#26 0x00007fa27ff1e19e in nsObserverService::NotifyObservers (this=0x23504c0, aSubject=0x21e5ce0, aTopic=0x7fa2805f999f "profile-change-teardown", someData=0x7fa2805f9b80)
    at /home/bjacob/mozilla-central/xpcom/ds/nsObserverService.cpp:182
#27 0x00007fa27e8b9e7c in nsXREDirProvider::DoShutdown (this=0x7fff2e39d1e0) at /home/bjacob/mozilla-central/toolkit/xre/nsXREDirProvider.cpp:799
#28 0x00007fa27e8a6fc4 in ScopedXPCOMStartup::~ScopedXPCOMStartup (this=0x7fff2e39d330, __in_chrg=<value optimized out>) at /home/bjacob/mozilla-central/toolkit/xre/nsAppRunner.cpp:1113
#29 0x00007fa27e8af8d5 in XRE_main (argc=5, argv=0x7fff2e39da18, aAppData=0x2167cc0) at /home/bjacob/mozilla-central/toolkit/xre/nsAppRunner.cpp:3712
#30 0x000000000040121f in main (argc=5, argv=0x7fff2e39da18) at /home/bjacob/mozilla-central/browser/app/nsBrowserApp.cpp:158
do you have a breakpad report? That would show the loaded modules.
How could I generate such a report? (it's not getting automatically generated, it's just crashing here.)
It just happened again and I took this occasion to print the values relevant to this assertion:

(gdb) print thread->data.nativeStackBase
$1 = (jsuword *) 0x7fffe5152000
(gdb) print GetNativeStackBase()
$2 = (jsuword *) 0x7fffe5151000

So there is a 4 KiB difference between these pointers.
Bad news: this crash is happening when running the WebGL mochitest hence it's blocking bug 582053 which is a betaN+ blocker!

To test:

MOZ_WEBGL_TEST_SUITE=1 TEST_PATH=content/canvas/test/webgl/test_webgl_conformance_test_suite.html make mochitest-plai
Blocks: 582053
in previous comment, please read mochitest-plain   (missing n)
The bug still exists in mozilla-central today. It's actually happening to me in so many pages, even about:home, that it seems to have nothing to do with the page.

The assertion is now at jscntxt.cpp:645  (instead of 651).

Even with all JIT preferences set to false, I still get this crash.

At this point it's fortunate that I'm leaving for a 1 week vacation now because I can't work :-( except perhaps by reverting to mozilla-central from 2 weeks ago.
Summary: crash: Assertion failure: thread->data.nativeStackBase == GetNativeStackBase(), at js/src/jscntxt.cpp:651 → crash: Assertion failure: thread->data.nativeStackBase == GetNativeStackBase(), at js/src/jscntxt.cpp:645
Here's the output of "info shared" in GDB:

From                To                  Syms Read   Shared Object Library
0x000000385ca05640  0x000000385ca10e48  Yes (*)     /lib64/libpthread.so.0
0x00007f6883e14da0  0x00007f6885b8d268  Yes         /home/bjacob/build/firefox/dist/bin/libxul.so
0x00007f68835177a0  0x00007f68835180a8  Yes         /home/bjacob/build/firefox/dist/bin/libxpcom.so
0x00007f6883313dd0  0x00007f6883314378  Yes         /home/bjacob/build/firefox/dist/bin/libmozalloc.so
0x00007f688310eef0  0x00007f6883110598  Yes         /home/bjacob/build/firefox/dist/bin/libplds4.so
0x00007f6882f0a3d0  0x00007f6882f0c3c8  Yes         /home/bjacob/build/firefox/dist/bin/libplc4.so
0x00007f6882cc6160  0x00007f6882cf5c78  Yes         /home/bjacob/build/firefox/dist/bin/libnspr4.so
0x000000385c600de0  0x000000385c601998  Yes (*)     /lib64/libdl.so.2
0x000000312f4681c0  0x000000312f70d268  Yes         /usr/lib64/libgtk-x11-2.0.so.0
0x0000003868a096b0  0x0000003868a150f8  Yes         /usr/lib64/libatk-1.0.so.0
0x000000386b819b60  0x000000386b8812c8  Yes         /lib64/libgio-2.0.so.0
0x0000003865e07650  0x0000003865e21348  Yes         /usr/lib64/libpangoft2-1.0.so.0
0x0000003863a0c850  0x0000003863a745a8  Yes         /usr/lib64/libfreetype.so.6
0x0000003863e05c80  0x0000003863e1ff28  Yes         /usr/lib64/libfontconfig.so.1
0x000000312fc1d260  0x000000312fc7f2a8  Yes         /usr/lib64/libgdk-x11-2.0.so.0
0x000000312ec05940  0x000000312ec17ba8  Yes         /usr/lib64/libgdk_pixbuf-2.0.so.0
0x000000312f004630  0x000000312f008eb8  Yes         /usr/lib64/libpangocairo-1.0.so.0
0x000000386700ede0  0x000000386702d768  Yes         /usr/lib64/libpango-1.0.so.0
0x0000003130c09c50  0x0000003130c5b058  Yes         /usr/lib64/libcairo.so.2
0x0000003860e08d20  0x0000003860e32a78  Yes         /lib64/libgobject-2.0.so.0
0x000000386b401080  0x000000386b401fc8  Yes         /lib64/libgmodule-2.0.so.0
0x0000003860601590  0x00000038606029f8  Yes         /lib64/libgthread-2.0.so.0
0x000000385d202140  0x000000385d2055a8  Yes (*)     /lib64/librt.so.1
0x000000385f6155c0  0x000000385f699d58  Yes         /lib64/libglib-2.0.so.0
0x000000385da1dd80  0x000000385daab938  Yes         /usr/lib64/libX11.so.6
0x000000312be563f0  0x000000312bec33f6  Yes (*)     /usr/lib64/libstdc++.so.6
0x000000385c203ea0  0x000000385c243fa8  Yes (*)     /lib64/libm.so.6
0x000000312b602910  0x000000312b612f48  Yes (*)     /lib64/libgcc_s.so.1
0x000000385be1e9a0  0x000000385bf2b820  Yes (*)     /lib64/libc.so.6
0x000000385ba00af0  0x000000385ba18904  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007f68829c9720  0x00007f6882a7c4b8  Yes         /home/bjacob/build/firefox/dist/bin/libmozsqlite3.so
0x00007f688278e870  0x00007f68827b1dc8  Yes         /home/bjacob/build/firefox/dist/bin/libsmime3.so
0x00007f6882539b90  0x00007f6882572af8  Yes         /home/bjacob/build/firefox/dist/bin/libssl3.so
0x00007f68821ab670  0x00007f68822e3f88  Yes         /home/bjacob/build/firefox/dist/bin/libnss3.so
0x00007f6881f74570  0x00007f6881f86198  Yes         /home/bjacob/build/firefox/dist/bin/libnssutil3.so
0x0000003864a018c0  0x0000003864a07f58  Yes         /usr/lib64/libXrender.so.1
0x000000386da2d6c0  0x000000386daadb98  Yes         /lib64/libasound.so.2
0x0000003860a07090  0x0000003860a2e4c8  Yes         /lib64/libdbus-1.so.3
0x000000386bc08f70  0x000000386bc194a8  Yes         /usr/lib64/libdbus-glib-1.so.2
0x000000312ae03530  0x000000312ae0e638  Yes (*)     /usr/lib64/libXext.so.6
0x00000031338130d0  0x000000313384f938  Yes         /usr/lib64/libXt.so.6
0x0000003865601370  0x0000003865604178  Yes         /usr/lib64/libXfixes.so.3
0x000000385f2038c0  0x000000385f212528  Yes (*)     /lib64/libresolv.so.2
0x000000385ce01ef0  0x000000385ce0d228  Yes         /lib64/libz.so.1
0x000000385e205550  0x000000385e215038  Yes         /lib64/libselinux.so.1
---Type <return> to continue, or q <return> to quit---
0x0000003863203b70  0x000000386321ca08  Yes         /lib64/libexpat.so.1
0x000000312e800a20  0x000000312e801508  Yes         /usr/lib64/libXinerama.so.1
0x000000312da01f00  0x000000312da0c7c8  Yes (*)     /usr/lib64/libXi.so.6
0x000000312de01720  0x000000312de06828  Yes         /usr/lib64/libXrandr.so.2
0x0000003864e02880  0x0000003864e07678  Yes         /usr/lib64/libXcursor.so.1
0x0000003136e00b40  0x0000003136e01908  Yes         /usr/lib64/libXcomposite.so.1
0x0000003873600a90  0x0000003873601638  Yes         /usr/lib64/libXdamage.so.1
0x000000312ce04830  0x000000312ce1e7a8  Yes (*)     /usr/lib64/libpng12.so.0
0x0000003867807230  0x0000003867851e78  Yes         /usr/lib64/libpixman-1.so.0
0x000000385de08650  0x000000385de13898  Yes         /usr/lib64/libxcb.so.1
0x000000312ba019f0  0x000000312ba062a8  Yes         /usr/lib64/libSM.so.6
0x000000385fe04d70  0x000000385fe13778  Yes         /usr/lib64/libICE.so.6
0x000000385d600dd0  0x000000385d601b68  Yes         /usr/lib64/libXau.so.6
0x000000312b2014b0  0x000000312b202be8  Yes (*)     /lib64/libuuid.so.1
0x0000003131022430  0x0000003131068f08  Yes         /usr/lib64/libgnomeui-2.so.0
0x000000313241dd70  0x0000003132454068  Yes         /usr/lib64/libbonoboui-2.so.0
0x0000003131c0bcf0  0x0000003131c28cd8  Yes         /usr/lib64/libgnomecanvas-2.so.0
0x0000003130806ee0  0x0000003130810e28  Yes         /usr/lib64/libgnome-2.so.0
0x0000003871402ef0  0x00000038714155e8  Yes         /usr/lib64/libart_lgpl_2.so.2
0x0000003130417900  0x000000313044f618  Yes         /usr/lib64/libgnomevfs-2.so.0
0x0000003869611b30  0x000000386962da28  Yes         /usr/lib64/libgconf-2.so.4
0x000000386d006d70  0x000000386d015bd8  Yes         /usr/lib64/libgnome-keyring.so.0
0x000000386c427fa0  0x000000386c452ee8  Yes         /usr/lib64/libbonobo-2.so.0
0x000000386c00adf0  0x000000386c012f58  Yes         /usr/lib64/libbonobo-activation.so.4
0x0000003868627990  0x000000386864b6a8  Yes         /usr/lib64/libORBit-2.so.0
0x0000003867e2c950  0x0000003867f09048  Yes         /usr/lib64/libxml2.so.2
0x0000003866601b10  0x0000003866606ee8  Yes         /lib64/libpopt.so.0
0x00000031320029a0  0x0000003132006178  Yes         /usr/lib64/libgailutil.so.18
0x000000312d614500  0x000000312d646708  Yes (*)     /usr/lib64/libssl.so.10
0x000000312ca5c900  0x000000312cb21288  Yes (*)     /lib64/libcrypto.so.10
0x0000003130000ca0  0x0000003130001aa8  Yes (*)     /usr/lib64/libavahi-glib.so.1
0x0000003131403390  0x0000003131408698  Yes (*)     /usr/lib64/libavahi-common.so.3
0x00000031318038b0  0x000000313180bf68  Yes (*)     /usr/lib64/libavahi-client.so.3
0x0000003873a00e10  0x0000003873a01688  Yes (*)     /lib64/libutil.so.1
0x0000003865a06d00  0x0000003865a50078  Yes         /lib64/libgcrypt.so.11
0x000000386b003110  0x000000386b003ad8  Yes         /usr/lib64/libORBitCosNaming-2.so.0
0x000000312c606c00  0x000000312c627268  Yes         /lib64/libgssapi_krb5.so.2
0x000000312d218540  0x000000312d273f08  Yes         /lib64/libkrb5.so.3
0x000000312c201220  0x000000312c201d08  Yes (*)     /lib64/libcom_err.so.2
0x00000038626055c0  0x000000386261e6b8  Yes         /lib64/libk5crypto.so.3
0x0000003872e007f0  0x0000003872e00d58  Yes         /lib64/libgpg-error.so.0
0x0000003861a026c0  0x0000003861a067b8  Yes         /lib64/libkrb5support.so.0
0x0000003861e00aa0  0x0000003861e00fa8  Yes         /lib64/libkeyutils.so.1
0x00007f687bebf110  0x00007f687bec7258  Yes (*)     /lib64/libnss_files.so.2
0x00007f687bcb9580  0x00007f687bcbace8  Yes (*)     /usr/lib64/gconv/UTF-16.so
0x00007f6878af10d0  0x00007f6878afa0d8  Yes         /home/bjacob/build/firefox/dist/bin/components/libmozgnome.so
---Type <return> to continue, or q <return> to quit---
0x00007f68788e92e0  0x00007f68788ec1f8  Yes         /usr/lib64/libnotify.so.1
0x00007f68786d9d90  0x00007f68786e1408  Yes         /home/bjacob/build/firefox/dist/bin/components/libdbusservice.so
0x00007f68784cac00  0x00007f68784d2648  Yes         /home/bjacob/build/firefox/dist/bin/components/libxpcomsample.so
0x00007f68782717e0  0x00007f68782ad8d8  Yes         /home/bjacob/build/firefox/dist/bin/components/libbrowsercomps.so
0x00007f687801e2b0  0x00007f6878061088  Yes (*)     /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so
0x0000003139600be0  0x0000003139601c08  Yes (*)     /usr/lib64/libXss.so.1
0x00007f687105fc50  0x00007f6871062938  Yes         /usr/lib64/gtk-2.0/2.10.0/immodules/im-xim.so
0x0000003134242000  0x00000031342a0b48  Yes (*)     /usr/lib64/nvidia/libGL.so.1
0x000000386ea14790  0x000000386f484c58  Yes (*)     /usr/lib64/nvidia/libGLcore.so.1
0x0000003809200740  0x0000003809200ce4  Yes (*)     /usr/lib64/nvidia/tls/libnvidia-tls.so.1
(*): Shared library is missing debugging information.



Here's a stack trace obtained in the same GDB session so we're sure that the addresses are consistent:


#0  0x000000385bea6a6d in nanosleep () from /lib64/libc.so.6
#1  0x000000385bea68e0 in sleep () from /lib64/libc.so.6
#2  0x00007f6883e46558 in ah_crap_handler (signum=6) at /home/bjacob/mozilla-central/toolkit/xre/nsSigHandlers.cpp:132
#3  0x00007f6883e4ad92 in nsProfileLock::FatalSignalHandler (signo=6, info=0x7fffe84ee9b0, context=0x7fffe84ee880) at nsProfileLock.cpp:221
#4  <signal handler called>
#5  0x000000385ca0f30b in raise () from /lib64/libpthread.so.0
#6  0x00007f6885819bd8 in JS_Assert (s=0x7f68860676d0 "thread->data.nativeStackBase == GetNativeStackBase()", file=0x7f68860673c0 "/home/bjacob/mozilla-central/js/src/jscntxt.cpp", ln=645)
    at /home/bjacob/mozilla-central/js/src/jsutil.cpp:83
#7  0x00007f68856e9c03 in js_CurrentThread (rt=0xe50530) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:645
#8  0x00007f68856e9c2a in js_InitContextThread (cx=0x2a08fa0) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:653
#9  0x00007f68856ea18e in js_NewContext (rt=0xe50530, stackChunkSize=8192) at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:790
#10 0x00007f68856acde2 in JS_NewContext (rt=0xe50530, stackChunkSize=8192) at /home/bjacob/mozilla-central/js/src/jsapi.cpp:970
#11 0x00007f6884774182 in nsJSContext::nsJSContext (this=0x2a08f30, aRuntime=0xe50530) at /home/bjacob/mozilla-central/dom/base/nsJSEnvironment.cpp:1303
#12 0x00007f688477b9eb in nsJSRuntime::CreateContext (this=0xecb850, aContext=0x7fffe84eef00) at /home/bjacob/mozilla-central/dom/base/nsJSEnvironment.cpp:3880
#13 0x00007f68847177ea in nsXBLDocGlobalObject::EnsureScriptEnvironment (this=0x2a08ef0, aLangID=2) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLDocumentInfo.cpp:317
#14 0x00007f6884717ad0 in nsXBLDocGlobalObject::GetContext (this=0x2a08ef0) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLDocumentInfo.cpp:351
#15 0x00007f68847208dd in nsXBLProtoImpl::CompilePrototypeMembers (this=0x1e95e60, aBinding=0x1ea4080) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLProtoImpl.cpp:165
#16 0x00007f68847205d5 in nsXBLProtoImpl::InitTargetObjects (this=0x1e95e60, aBinding=0x1ea4080, aContext=0x210e440, aBoundElement=0x22dad80, aScriptObjectHolder=0x7fffe84ef170, 
    aTargetClassObject=0x7fffe84ef168) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLProtoImpl.cpp:111
#17 0x00007f68847203d1 in nsXBLProtoImpl::InstallImplementation (this=0x1e95e60, aBinding=0x1ea4080, aBoundElement=0x22dad80)
    at /home/bjacob/mozilla-central/content/xbl/src/nsXBLProtoImpl.cpp:79
#18 0x00007f68847111be in nsXBLPrototypeBinding::InstallImplementation (this=0x1ea4080, aBoundElement=0x22dad80) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLPrototypeBinding.cpp:539
#19 0x00007f688470c9df in nsXBLBinding::InstallImplementation (this=0x1e95de0) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLBinding.cpp:940
#20 0x00007f688470c93c in nsXBLBinding::InstallImplementation (this=0x1e8fe50) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLBinding.cpp:934
#21 0x00007f6884729dac in nsXBLService::LoadBindings (this=0x1027220, aContent=0x22dad80, aURL=0x1542890, aOriginPrincipal=0xebcdd0, aAugmentFlag=0, aBinding=0x1d84cd0, aResolveStyle=
    0x7fffe84ef51c) at /home/bjacob/mozilla-central/content/xbl/src/nsXBLService.cpp:647
#22 0x00007f68840dfe32 in nsCSSFrameConstructor::AddFrameConstructionItemsInternal (this=0x21d31b0, aState=..., aContent=0x22dad80, aParentFrame=0x1e9b8e0, aTag=0xe44040, aNameSpaceID=9, 
    aSuppressWhiteSpaceOptimizations=0, aStyleContext=0x1e9bab8, aFlags=3, aItems=...) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5126
#23 0x00007f68840dfbac in nsCSSFrameConstructor::AddFrameConstructionItems (this=0x21d31b0, aState=..., aContent=0x22dad80, aSuppressWhiteSpaceOptimizations=0, aParentFrame=0x1e9b8e0, 
    aItems=...) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5066
#24 0x00007f68840eaa4a in nsCSSFrameConstructor::ProcessChildren (this=0x21d31b0, aState=..., aContent=0x22d9590, aStyleContext=0x1edd700, aFrame=0x1e9b8e0, aCanHaveGeneratedContent=1, 
    aFrameItems=..., aAllowBlockStyles=1, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9576
#25 0x00007f68840ed23c in nsCSSFrameConstructor::ConstructBlock (this=0x21d31b0, aState=..., aDisplay=0x21d4878, aContent=0x22d9590, aParentFrame=0x1edd648, aContentParentFrame=0x1edd648, 
    aStyleContext=0x1edd700, aNewFrame=0x7fffe84efb20, aFrameItems=..., aAbsPosContainer=0, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:10641
#26 0x00007f68840deb1d in nsCSSFrameConstructor::ConstructNonScrollableBlock (this=0x21d31b0, aState=..., aItem=..., aParentFrame=0x1edd648, aDisplay=0x21d4878, aFrameItems=..., aNewFrame=
    0x7fffe84efb20) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:4531
#27 0x00007f68840dd0ff in nsCSSFrameConstructor::ConstructFrameFromItemInternal (this=0x21d31b0, aItem=..., aState=..., aParentFrame=0x1edd648, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:3728
#28 0x00007f68840e0ce5 in nsCSSFrameConstructor::ConstructFramesFromItem (this=0x21d31b0, aState=..., aIter=..., aParentFrame=0x1edd648, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5481
#29 0x00007f68840f42cb in nsCSSFrameConstructor::ConstructFramesFromItemList (this=0x21d31b0, aState=..., aItems=..., aParentFrame=0x1edd648, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9475
#30 0x00007f68840eab38 in nsCSSFrameConstructor::ProcessChildren (this=0x21d31b0, aState=..., aContent=0x17d6a70, aStyleContext=0x22d8120, aFrame=0x1edd648, aCanHaveGeneratedContent=1, 
    aFrameItems=..., aAllowBlockStyles=1, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9591
#31 0x00007f68840ed23c in nsCSSFrameConstructor::ConstructBlock (this=0x21d31b0, aState=..., aDisplay=0x21d4878, aContent=0x17d6a70, aParentFrame=0x22d7d38, aContentParentFrame=0x22d7d38, 
    aStyleContext=0x22d8120, aNewFrame=0x7fffe84f01c0, aFrameItems=..., aAbsPosContainer=0, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:10641
---Type <return> to continue, or q <return> to quit---
#32 0x00007f68840deb1d in nsCSSFrameConstructor::ConstructNonScrollableBlock (this=0x21d31b0, aState=..., aItem=..., aParentFrame=0x22d7d38, aDisplay=0x21d4878, aFrameItems=..., aNewFrame=
    0x7fffe84f01c0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:4531
#33 0x00007f68840dd0ff in nsCSSFrameConstructor::ConstructFrameFromItemInternal (this=0x21d31b0, aItem=..., aState=..., aParentFrame=0x22d7d38, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:3728
#34 0x00007f68840e0ce5 in nsCSSFrameConstructor::ConstructFramesFromItem (this=0x21d31b0, aState=..., aIter=..., aParentFrame=0x22d7d38, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5481
#35 0x00007f68840f42cb in nsCSSFrameConstructor::ConstructFramesFromItemList (this=0x21d31b0, aState=..., aItems=..., aParentFrame=0x22d7d38, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9475
#36 0x00007f68840eab38 in nsCSSFrameConstructor::ProcessChildren (this=0x21d31b0, aState=..., aContent=0x17d6090, aStyleContext=0x22d7790, aFrame=0x22d7d38, aCanHaveGeneratedContent=1, 
    aFrameItems=..., aAllowBlockStyles=1, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9591
#37 0x00007f68840ed23c in nsCSSFrameConstructor::ConstructBlock (this=0x21d31b0, aState=..., aDisplay=0x22d7b50, aContent=0x17d6090, aParentFrame=0x22d7928, aContentParentFrame=0x22d7928, 
    aStyleContext=0x22d7790, aNewFrame=0x7fffe84f0860, aFrameItems=..., aAbsPosContainer=1, aPendingBinding=0x0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:10641
#38 0x00007f68840deb1d in nsCSSFrameConstructor::ConstructNonScrollableBlock (this=0x21d31b0, aState=..., aItem=..., aParentFrame=0x22d7928, aDisplay=0x22d7b50, aFrameItems=..., aNewFrame=
    0x7fffe84f0860) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:4531
#39 0x00007f68840dd0ff in nsCSSFrameConstructor::ConstructFrameFromItemInternal (this=0x21d31b0, aItem=..., aState=..., aParentFrame=0x22d7928, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:3728
#40 0x00007f68840e0ce5 in nsCSSFrameConstructor::ConstructFramesFromItem (this=0x21d31b0, aState=..., aIter=..., aParentFrame=0x22d7928, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:5481
#41 0x00007f68840f42cb in nsCSSFrameConstructor::ConstructFramesFromItemList (this=0x21d31b0, aState=..., aItems=..., aParentFrame=0x22d7928, aFrameItems=...)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:9475
#42 0x00007f68840e3bd3 in nsCSSFrameConstructor::ContentAppended (this=0x21d31b0, aContainer=0x21a74e0, aFirstNewContent=0x21d4e70, aAllowLazyConstruction=0)
    at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6661
#43 0x00007f68840e2f31 in nsCSSFrameConstructor::CreateNeededFrames (this=0x21d31b0, aContent=0x21a74e0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6328
#44 0x00007f68840e2f9f in nsCSSFrameConstructor::CreateNeededFrames (this=0x21d31b0, aContent=0x21edd40) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6338
#45 0x00007f68840e30bc in nsCSSFrameConstructor::CreateNeededFrames (this=0x21d31b0) at /home/bjacob/mozilla-central/layout/base/nsCSSFrameConstructor.cpp:6353
#46 0x00007f688416608c in PresShell::FlushPendingNotifications (this=0x21d19e0, aType=Flush_Style) at /home/bjacob/mozilla-central/layout/base/nsPresShell.cpp:4848
#47 0x00007f6884455614 in nsDocument::FlushPendingNotifications (this=0x21c6750, aType=Flush_Style) at /home/bjacob/mozilla-central/content/base/src/nsDocument.cpp:6428
#48 0x00007f6884e33381 in nsDocLoader::DocLoaderIsEmpty (this=0x2106b00, aFlushLayout=1) at /home/bjacob/mozilla-central/uriloader/base/nsDocLoader.cpp:772
#49 0x00007f6884e3304e in nsDocLoader::OnStopRequest (this=0x2106b00, aRequest=0x213b3c0, aCtxt=0x0, aStatus=0) at /home/bjacob/mozilla-central/uriloader/base/nsDocLoader.cpp:702
#50 0x00007f6883e98acd in nsLoadGroup::RemoveRequest (this=0x211ebe0, request=0x213b3c0, ctxt=0x0, aStatus=0) at /home/bjacob/mozilla-central/netwerk/base/src/nsLoadGroup.cpp:680
#51 0x00007f6884458557 in nsDocument::DoUnblockOnload (this=0x21c6750) at /home/bjacob/mozilla-central/content/base/src/nsDocument.cpp:7259
#52 0x00007f6884458318 in nsDocument::UnblockOnload (this=0x21c6750, aFireSync=1) at /home/bjacob/mozilla-central/content/base/src/nsDocument.cpp:7201
#53 0x00007f688444d58b in nsDocument::DispatchContentLoadedEvents (this=0x21c6750) at /home/bjacob/mozilla-central/content/base/src/nsDocument.cpp:4182
#54 0x00007f688446a0de in nsRunnableMethodImpl<void (nsDocument::*)(), true>::Run (this=0x17d6610) at ../../../dist/include/nsThreadUtils.h:347
#55 0x00007f688550287d in nsThread::ProcessNextEvent (this=0xc1b5b0, mayWait=0, result=0x7fffe84f13bc) at /home/bjacob/mozilla-central/xpcom/threads/nsThread.cpp:609
#56 0x00007f688548e310 in NS_ProcessNextEvent_P (thread=0xc1b5b0, mayWait=0) at nsThreadUtils.cpp:250
#57 0x00007f68852f308a in mozilla::ipc::MessagePump::Run (this=0xc2ce70, aDelegate=0xc1b270) at /home/bjacob/mozilla-central/ipc/glue/MessagePump.cpp:110
#58 0x00007f6885568fc3 in MessageLoop::RunInternal (this=0xc1b270) at /home/bjacob/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#59 0x00007f6885568f48 in MessageLoop::RunHandler (this=0xc1b270) at /home/bjacob/mozilla-central/ipc/chromium/src/base/message_loop.cc:202
#60 0x00007f6885568ed9 in MessageLoop::Run (this=0xc1b270) at /home/bjacob/mozilla-central/ipc/chromium/src/base/message_loop.cc:176
#61 0x00007f6885195fa3 in nsBaseAppShell::Run (this=0xf01a50) at /home/bjacob/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:181
#62 0x00007f6884ee75f5 in nsAppStartup::Run (this=0x1020c50) at /home/bjacob/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:191
#63 0x00007f6883e380f7 in XRE_main (argc=5, argv=0x7fffe84f2018, aAppData=0xbb6cc0) at /home/bjacob/mozilla-central/toolkit/xre/nsAppRunner.cpp:3682
#64 0x000000000040121f in main (argc=5, argv=0x7fffe84f2018) at /home/bjacob/mozilla-central/browser/app/nsBrowserApp.cpp:158
Can't repro on my x64/Linux box. What distro/version?
This is on Fedora 13, x86-64.
By the way, my mozconfig has disable-jemalloc and enable-valgrind.
I will try to add better assert coverage
Assignee: general → igor
I am also seeing this, but crashing on launch of a newly built firefox.
adding my backtrace - this is on 32 bit ubuntu
Here's a patch that adds printf's in js_CurrentThread() and in GetNativeStackBaseImpl().


I get first lots of normal output, like this:

    begin js_CurrentThread, id = 0x605a60
    locked GC
    bool p = 1
    id         = 0x605a60
    thread->id = 0x605a60
    thread->data.nativeStackBase = 0x7ffffffff000
    stackBase = 0x7fffff5ff000
    stackSize = a00000
    JS_STACK_GROWTH_DIRECTION = -1
    GetNativeStackBase()         = 0x7ffffffff000
    end js_CurrentThread, return value = 0x7fffec484010


But when it eventually crashes, here's the output:

    begin js_CurrentThread, id = 0x605a60
    locked GC
    bool p = 1
    id         = 0x605a60
    thread->id = 0x605a60
    thread->data.nativeStackBase = 0x7ffffffff000
    stackBase = 0x7fffff5fe000
    stackSize = a00000
    JS_STACK_GROWTH_DIRECTION = -1
    GetNativeStackBase()         = 0x7fffffffe000


Here, stackBase and stackSize are the values obtained in GetNativeStackBaseImpl(), by this code:

    pthread_attr_getstack(&sattr, &stackBase, &stackSize);

So what we have here is that the pthreads stack base has moved under our feet, by 4k!
I also checked that the pthread_t object in GetNativeStackBaseImpl() is really always the same.
Valgrind doesn't report any error, so it shouldn't be a heap corruption.
To be clear: when run under valgrind, I don't get any crash or error at all.
I can't repro this on x86_64-Linux (Ubuntu 10.04).

Feels like it should be easy to pin down once it can be repro'd.
One thing we could do is look at /proc/self/maps at the point when
the assertion fails, in order to see if it has changed its story
about the status/ownership/whatever of the last page in the
relevant thread's stack.
I see this from time to time when valgrinding mochitests, and it
bothers me.  I wonder if it's somehow related to what's going on
here.

Invalid read of size 8
   at 0x6E2F289: js::MarkRangeConservatively(JSTracer*, unsigned long*,
                 unsigned long*) (js/src/jsgc.cpp:710)
   by 0x6E2F432: js::MarkConservativeStackRoots(JSTracer*)
                 (js/src/jsgc.cpp:728)
   by 0x6E33C27: js::MarkRuntime(JSTracer*) (js/src/jsgc.cpp:1620)
   by 0x6E34A6C: MarkAndSweep(JSContext*, JSGCInvocationKind)
                 (js/src/jsgc.cpp:2171)
   by 0x6E36307: js_GC(JSContext*, JSGCInvocationKind) (js/src/jsgc.cpp:2515)
   by 0x6DA3D64: JS_GC (js/src/jsapi.cpp:2513)
   by 0x642281C: nsXPConnect::Collect() (js/src/xpconnect
                 /src/nsXPConnect.cpp:404)
   by 0x64205BC: nsXPConnect::GarbageCollect() (js/src/xpconnect
                 /src/nsXPConnect.cpp:412)
   by 0x5F0F4A3: nsJSContext::CC(nsICycleCollectorListener*) (dom/base
                 /nsJSEnvironment.cpp:3628)
   by 0x5F0F506: nsJSContext::IntervalCC() (dom/base/nsJSEnvironment.cpp:3733)
   by 0x5F0F5F9: nsJSContext::MaybeCC(int) (dom/base/nsJSEnvironment.cpp:3702)
   by 0x5F0F622: nsJSContext::MaybeCCIfUserInactive() (dom/base
                 /nsJSEnvironment.cpp:3723)
 Address 0x7feffc460 is just below the stack ptr.
  To suppress, use: --workaround-gcc296-bugs=yes
Here's the /procs/the-pid-of-firefox/maps file when it's crashed.

The relevant addresses are:

(gdb) print GetNativeStackBase()
$1 = (jsuword *) 0x7fffffffe000
(gdb) print thread->data.nativeStackBase
$2 = (jsuword *) 0x7ffffffff000
(In reply to comment #23)
> maps file for firefox process when it's crashed
(In reply to comment #24)
> maps file for firefox process BEFORE it's crashed

This is interesting.  After it has crashed, we have the end of the
maps looking like this:

7ffff7fee000-7ffff7ff6000 rwxp 00000000 00:00 0 
7ffff7ff6000-7ffff7ffd000 r--s 00000000 08:05 6430                       /usr/lib64/gconv/gconv-modules.cache
7ffff7ffd000-7ffff7ffe000 rw-p 00000000 00:00 0 
7ffff7ffe000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
7ffffffde000-7fffffffe000 rwxp 00000000 00:00 0                          [stack]
7fffffffe000-7ffffffff000 rw-p 00000000 00:00 0 
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

so we have a mysterious rw- page at the end of the stack, and the main
part of the stack is rwx.  (which is odd)

Before the crash, it looked more like I'd expect:

7ffff7ffe000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
7ffffffea000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

... a single rw- segment.

So this is pretty strange.  It's as if the whole of the stack except
for the last page has been changed from rw- to rwx (which sounds
pretty dodgy in itself).  Then, pthread_attr_getstack returns data
from this new one-page-shortened stack, which leads to the observed
single page discrepancy causing the assertion.

So how, why, did that permission change happen?  That's the next thing
to find out.
(In reply to comment #25)
> 
> So this is pretty strange.  It's as if the whole of the stack except
> for the last page has been changed from rw- to rwx (which sounds
> pretty dodgy in itself).  Then, pthread_attr_getstack returns data
> from this new one-page-shortened stack, which leads to the observed
> single page discrepancy causing the assertion.
> 
> So how, why, did that permission change happen?  That's the next thing
> to find out.

Julian, are you continuing to investigate this? (that would be awesome)
> Julian, are you continuing to investigate this?

Yes, but having to use bjacob as a remote debug server as I can't
repro it myself.
Sent strace log privately to Julian as he tells me this could contain private information.
(In reply to comment #17)
> So what we have here is that the pthreads stack base has moved under our feet,
> by 4k!

That was what I had concluded in bug 607146 as well.
(In reply to comment #29)
> (In reply to comment #17)
> > So what we have here is that the pthreads stack base has moved under our feet,
> > by 4k!
> 
> That was what I had concluded in bug 607146 as well.

I can't see that either the kernel or libpthread has the ability to
move a thread stack around without totally breaking the program.  For
it to do so would require it to fix up all values which had been
computed from the form 'sp + offset', and I don't see how it could
possibly do that.

Also, it doesn't explain the observation that the main part of the
stack changed from rw- to rwx, in comment 25.

My current hypothesis is that someone mprotected "rwx" the first N-1
pages of the stack, and this has fooled the stack base detection 
algorithm.
I am starting to wonder if this could be a glibc 2.12.0 bug that's been fixed in glibc 2.12.1. Indeed, since I upgraded to 2.12.1, I've not been able to reproduce the crash anymore.

Other people having this crash, what's your glibc version (and distro) ?
> Other people having this crash, what's your glibc version (and distro) ?

Also, it would be useful to know if you're using /usr/lib64/nvidia/libGL.so.1
(I'm not saying it's a bug in Nvidia's libGL.so; see next comment)
Still deep in hypothesis territory, but: current working hypothesis,
after some remote debugging on Benoit's machine, is that it's a bad
interaction between a glibc bug and our (imo overly fragile)
stack-base detection logic.

1.  GetNativeStackBaseImpl() gets a (correct) value for the main
    thread's stack, and stashes it in thread->data.nativeStackBase

2.  The main thread dlopens /usr/lib64/nvidia/libGL.so.1, which
    has a note in its ELF header saying "I require executable stack"

3.  Up to this point, the main thread's stack has been mapped "rw-",
    so dlopen duly mprotects it "rwx" | PROT_GROWSDOWN instead.
    Except it screws up and fails to mark the highest-addressed page
    of the stack.  It needs to mark the area also with PROT_GROWSDOWN
    (is automatically extended downwards by the kernel when page
    faults happen) so that auto-stack-extension still works, as is
    required on a linux main thread.

    Consequently the stack is now split into a rwx|PROT_GROWSDOWN
    section and a trailing rw- page.

4.  JS_ASSERT in js_CurrentThread calls GetNativeStackBaseImpl().
    This calls pthread_attr_getstack as before, but now gets the wrong
    answer, because the kernel believes the stack segment is only the
    part that was mprotected in step 3.  (see my hands waving?)

5.  Assertion fails.

I'll dig around in libc sources tomorrow to see if this holds water.
(In reply to comment #32)
> > Other people having this crash, what's your glibc version (and distro) ?
> 
2.11.1-0ubuntu7.5 (Lucid seems to be out of date here)

> Also, it would be useful to know if you're using /usr/lib64/nvidia/libGL.so.1
> (I'm not saying it's a bug in Nvidia's libGL.so; see next comment)

nope, intel and 32 bit
(In reply to comment #34)
> nope, intel and 32 bit

Well, does the relevant driver require an executable stack?
What does /usr/sbin/execstack -q say about it?
(In reply to comment #33)
> Still deep in hypothesis territory, [...]

That probably seems like rather a large leap.  Here's some
background.

We're looking for some event that causes the stack mapping to
morph from this (looks ok)

   7fffdbde6000-7fffdbde9000 rw-p 00000000 00:00 0          [stack]

to this (looks strange)

   7fffdbdc7000-7fffdbde7000 rwxp 00000000 00:00 0          [stack]
   7fffdbde7000-7fffdbde9000 rw-p 00000000 00:00 0 

The most obvious candidate would be an errant mprotect syscall.
A bit of peering at strace logs and map entries provides this

  mprotect(0x7fffdbde6000, 4096,
           PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0

That just marks the lowest page rwx, but that is auto-extended
downwards as the stack later grows.  Anyway, we want to know where
this happened.  In principle this is found by breakpointing mprotect
and inspecting the args; in practice it's faster and easier to run on
a hacked valgrind that prints the stack at each mprotect call.  This
points the finger at

   at 0x4016F97: mprotect (sysdeps/unix/syscall-template.S:82)
   by 0x4011BEA: _dl_make_stack_executable (sysdeps/unix/sysv/linux
                 /dl-execstack.c:57)
   by 0x4C273FA: __make_stacks_executable (nptl/allocatestack.c:763)
   by 0x4007FB7: _dl_map_object_from_fd (elf/dl-load.c:1415)
   by 0x40082A7: _dl_map_object (elf/dl-load.c:2249)
   by 0x40128D8: dl_open_worker (elf/dl-open.c:255)
   by 0x400E015: _dl_catch_error (elf/dl-error.c:178)
   by 0x4012369: _dl_open (elf/dl-open.c:584)
   by 0x8F5DF65: dlopen_doit (dlfcn/dlopen.c:67)
   by 0x400E015: _dl_catch_error (elf/dl-error.c:178)
   by 0x8F5E29B: _dlerror_run (dlfcn/dlerror.c:164)
   by 0x8F5DEE0: dlopen@@GLIBC_2.2.5 (dlfcn/dlopen.c:88)
   by 0x8D271D6: pr_LoadLibraryByPathname (nsprpub/pr/src/linking/prlink.c:836)
   by 0x8D270A8: PR_LoadLibraryWithFlags (nsprpub/pr/src/linking/prlink.c:451)
   by 0x8D270FF: PR_LoadLibrary (nsprpub/pr/src/linking/prlink.c:475)
   by 0x6D8DE64: mozilla::gl::GLXLibrary::EnsureInitialized()
                 (gfx/thebes/GLContextProviderGLX.cpp:98)
   by 0x6D8E6CE: mozilla::gl::GLContextProviderGLX::CreateForWindow
                 (gfx/thebes/GLContextProviderGLX.cpp:499)
   by 0x6DABCF2: mozilla::layers::LayerManagerOGL::Initialize
                 (gfx/layers/opengl/LayerManagerOGL.cpp:179)

More peering at strace output suggests this is probably the result of
dlopening /usr/lib64/nvidia/libGL.so.1.  Why would ld.so want to screw
with stack permissions at this point?  Because
/usr/lib64/nvidia/libGL.so.1 needs an executable stack:

   # execstack -q /usr/lib64/nvidia/libGL.so.1
   X /usr/lib64/nvidia/libGL.so.1

One inference from all this is that the failure has nothing per se
to do with the JS engine.  It just happens to show up there because
that's the only part of the system that cares about the address ranges
of the valid bits of the stack(s).
So in conclusion, for future people hitting this crash:
  * if possible, upgrade glibc to version 2.12.1  (bug only confirmed with 2.12.0 and 2.11.1)
  * otherwise, as a partial work-around, disable GL layers (in about:config set layers.accelerate...) though you'll still get crashes with WebGL.

Now looking at glibc changes in 2.12.1...
Generated by:

  git log --name-only glibc-2.12..glibc-2.12.1
Generated by:

  git log -p glibc-2.12..glibc-2.12.1

Compressed with xz.
Sorry, forget all I said about glibc 2.12.1. I still get the crash with 2.12.1, it's just that the STR change a little bit, but here's very simple STR that consistently crash, with 2.12.1:

  1. start firefox
  2. click in the URL bar
  3. select all the contents of the URL bar  (ctrl+A)
  4. type a letter, for example A


Also, I confirm that in doesn't crash if I disable GL layers and don't visit a WebGL page, so that libGL.so.1 doesn't get loaded.
Here are more execstack results with other drivers:

Intel driver (Mesa GL):

   - /usr/lib/mesa/libGL.so.1
   - /usr/lib64/mesa/libGL.so.1

ATI proprietary driver (FGLRX):

   - /usr/lib/libGL.so.1
   - /usr/lib/fglrx/diversions/libGL.so.1


So far, only the NVIDIA proprietary driver seems to require an executable stack.
(In reply to comment #34)
> (In reply to comment #32)
> > Also, it would be useful to know if you're using /usr/lib64/nvidia/libGL.so.1
> > (I'm not saying it's a bug in Nvidia's libGL.so; see next comment)
> 
> nope, intel and 32 bit

Can you please do:

   execstack -q /path/to/libGL.so.1

?

You may have to install execstack.
Here's a small test case showing dlopen of a .so requiring executable
stack defeating GetNativeStackBaseImpl.  It prints the last 5 lines
of /proc/self/maps for itself and also calls GetNativeStackBaseImpl.
It does this twice, and in between dlopens a test .so.  When the .so
has been execstack -s'd, the we see the stack segment split in 
the procmap output, and the two calls to GetNativeStackBaseImpl
producing different values.

What's even weirder is it fails differently on different runs.
Sometimes the two stack base values are identical, sometimes
differ by 1 page, and sometimes by 2 pages.

This is on Ubuntu 10.04 on x86_64.

  $ gcc -g -Wall -shared -o try1so.so try1so.c
  $ gcc -g -Wall -o try1 try1.c -ldl -lpthread
  $ execstack -q ./try1so.so 
  - ./try1so.so
  $ ./try1   ## the two stack base numbers are always the same

  $ execstack -s ./try1so.so 
  $ execstack -q ./try1so.so 
  X ./try1so.so
  $ ./try1   ## the two stack base numbers differ by 0, 1 or 2
             ## pages
This really seems to me like a glibc bug.  After some experimentation
I can only get earlier and later versions of the values returned
by GetNativeStackBaseImpl to differ by 0, 1 or 2 pages, so perhaps
as a workaround on Linux we can relax the failing assertion thusly?

    char* gnsb = (char*)GetNativeStackBase();
    JS_ASSERT(gnsb + 0    == thread->data.nativeStackBase ||
              gnsb + 4096 == thread->data.nativeStackBase ||
              gnsb + 8192 == thread->data.nativeStackBase);
I applied this diff to get it to compile (char != jsuword)

-    // JS_ASSERT(thread->data.nativeStackBase == GetNativeStackBase());
+    char* gnsb = (char*) GetNativeStackBase();
+    JS_ASSERT(gnsb + 0    == (char*) thread->data.nativeStackBase ||
+              gnsb + 4096 == (char*) thread->data.nativeStackBase ||
+              gnsb + 8192 == (char*) thread->data.nativeStackBase);

I confirm it works here, no crash.
(In reply to comment #42)

> Can you please do:
> 
>    execstack -q /path/to/libGL.so.1

execstack -q /usr/lib/fglrx/libGL.so.1
- /usr/lib/fglrx/libGL.so.1

The drivers loaded are: xserver-xorg-video-intel and xserver-xorg-video-i740
Why do you have the FGLRX (proprietary ATI) GL installed at all? I don't think it's used at all. You can check this by doing

   grep libGL.so.1 /proc/THE_PID_OF_FIREFOX/maps

where THE_PID_OF_FIREFOX has been replaced by the pid of firefox. (ldd won't help here because we're dlopen'ing the GL at runtime).

What's the result of

   find -name libGL.so.1 /usr

? I bet there is another file there, that's actually used on your intel-based system.
As requested by Julian, I confirm it's giving me the same results on Fedora 13 / x86-64  (glibc 2.12.1 gcc 4.4.4)

[bjacob@cahouette ~]$ tar xf smalltestcase.tar 
[bjacob@cahouette ~]$ gcc -g -Wall -shared -o try1so.so try1so.c
[bjacob@cahouette ~]$ gcc -g -Wall -o try1 try1.c -ldl -lpthread
[bjacob@cahouette ~]$ execstack -q ./try1so.so
- ./try1so.so
[bjacob@cahouette ~]$ ./try1

7f9a3c7d2000-7f9a3c7d5000 rw-p 00000000 00:00 0 
7f9a3c7f2000-7f9a3c7f4000 rw-p 00000000 00:00 0 
7ffffb267000-7ffffb27c000 rw-p 00000000 00:00 0                          [stack]
7ffffb34d000-7ffffb34e000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
GetNativeStackBase returns 0x7ffffb27c000

7f9a3c7d2000-7f9a3c7d5000 rw-p 00000000 00:00 0 
7f9a3c7f2000-7f9a3c7f4000 rw-p 00000000 00:00 0 
7ffffb267000-7ffffb27c000 rw-p 00000000 00:00 0                          [stack]
7ffffb34d000-7ffffb34e000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
GetNativeStackBase returns 0x7ffffb27c000

[bjacob@cahouette ~]$ execstack -s ./try1so.so
[bjacob@cahouette ~]$ execstack -q ./try1so.so
X ./try1so.so
[bjacob@cahouette ~]$ ./try1

7f7e4ae7d000-7f7e4ae80000 rw-p 00000000 00:00 0 
7f7e4ae9d000-7f7e4ae9f000 rw-p 00000000 00:00 0 
7fff8f56b000-7fff8f580000 rw-p 00000000 00:00 0                          [stack]
7fff8f5ff000-7fff8f600000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
GetNativeStackBase returns 0x7fff8f580000

7f7e4ae9d000-7f7e4ae9f000 rw-p 00000000 00:00 0 
7fff8f56b000-7fff8f57e000 rwxp 00000000 00:00 0                          [stack]
7fff8f57e000-7fff8f580000 rw-p 00000000 00:00 0 
7fff8f5ff000-7fff8f600000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
GetNativeStackBase returns 0x7fff8f57e000
(In reply to comment #44)
> I can only get earlier and later versions of the values returned
> by GetNativeStackBaseImpl to differ by 0, 1 or 2 pages, so perhaps
> as a workaround on Linux we can relax the failing assertion thusly?

That potentially creates 2 pages of GC hazards for conservative stack scanning, no?
Bad news, it actually can be 3 pages off! With the patch from comment 45 applied:


Assertion failure: gnsb + 0 == (char*) thread->data.nativeStackBase || gnsb + 4096 == (char*) thread->data.nativeStackBase || gnsb + 8192 == (char*) thread->data.nativeStackBase, at /home/bjacob/mozilla-central/js/src/jscntxt.cpp:649


(gdb) print gnsb
$1 = 0x7fff5c1f0000
(gdb) print thread->data.nativeStackBase
$2 = (jsuword *) 0x7fff5c1f3000
(In reply to comment #50)
> (In reply to comment #44)
> > I can only get earlier and later versions of the values returned
> > by GetNativeStackBaseImpl to differ by 0, 1 or 2 pages, so perhaps
> > as a workaround on Linux we can relax the failing assertion thusly?
> 
> That potentially creates 2 pages of GC hazards for conservative stack scanning,
> no?

Well, it would if we used the later-calculated values from
GetNativeStackBaseImpl(), since these miss out the 1 or 2 pages.  But
it appears we acquire and cache and use the results of the first call
(in each thread), so we're OK.

It's unedifying fragile though, that's for sure.
I just wonder about this assertion : just before it there is already an assertion that the thread id is correct:

    JS_ASSERT(thread->id == id);

So is the assertion on stack addresses really needed?
(In reply to comment #53)
> So is the assertion on stack addresses really needed?

I would think threads can migrate if they have no code running on them, not sure whether that would happen in practice... /me wonders if that was what the assertion was originally testing.
(In reply to comment #54)
> no code running on them

Sorry, by this I meant an empty stack, not that the thread is suspended.
(In reply to comment #53)
> So is the assertion on stack addresses really needed?

I would be reluctant to get rid of it.  For one thing it just told us
that GetNativeStackBase was misbehaving.

I think it's a useful safety check.  If a thread switches to a
different stacks, either by explicitly writing to its SP register, by
taking a signal on an altstack, or whatever other mutant things can
happen on non-Unix platforms, we need to know.

---

Currently on Linux we are OK despite this bug, because as far as we
know, we use the value obtained from GetNativeStackBase before the
dlopening of the offending (execstack) shared object.  But if
firefox-bin ever came to be linked against said shared object, it
would be mapped in at startup, before we got to main(), and
GetNativeStackBase would then give us a bogus value.

Can't we establish the stack bases by recording the addresses of a
local variable in main() and in the root frame of each new thread?
This would mean we weren't exposed to such bugs in the underlying
thread libraries, and would mean a single implementation would work
across all platforms, rather than the current ifdeffery in
jsnativestack.cpp.

Not proposing this as a short term fix for 4.0, but maybe for later.
(In reply to comment #54)
> I would think threads can migrate if they have no code running on
> them,

I do know that glibc will recycle thread stacks, so it doesn't have
the overhead of unmapping and remapping stacks in apps that create and
destroy threads frequently.  But there's no monkey business with
stacks whilst a thread is still alive (afaik!).
This is Julian's idea for working around this presumed glibc bug: add some tolerance in the stack address comparison: allow it to be 1, 2, or 3 pages off. The value 3 here is just empirical, it just happens to be the biggest number of pages we've seen it being off by.

Not asking for review, this isn't even my patch :) just making it easy to find.
c59 patch does "char* gnsb = (char*) GetNativeStackBase();"
unnecessarily in release builds, and I don't think compilers
will be able to optimize the call away.  Hence wrap it up in
#ifdef DEBUG.
Attachment #492204 - Attachment is obsolete: true
Attachment #491177 - Attachment is obsolete: true
Attachment #491178 - Attachment is obsolete: true
I am seeing this problem when I run reftests, but not when I run the browser... this is on Ubuntu 10.04 32bit, NVidia drivers.
I guess that the GL reftests take care of enabling GL layers. If you go to about:config and set layers.accelerate-all=true, maybe you'll get the crash in the browser.
(In reply to comment #62)
> I guess that the GL reftests take care of enabling GL layers. If you go to
> about:config and set layers.accelerate-all=true, maybe you'll get the crash in
> the browser.

Tested now. Indeed, that is exactly what happens.
(In reply to comment #63)
> Tested now. Indeed, that is exactly what happens.

And if you apply the patch in comment 60 and try again, does that remove
all the crashes?  That would be useful to know.
Yes, the patch fixes all the crashes I experience.
Attachment #492229 - Attachment is obsolete: true
Attachment #492617 - Flags: review?(jimb)
Attachment #492617 - Flags: review?(jimb) → review+
Attachment #492617 - Flags: approval2.0?
Attachment #492617 - Flags: approval2.0? → approval2.0+
Pushed the patch from comment 66:
http://hg.mozilla.org/mozilla-central/rev/73caba953b11

Not closing this bug, as that's only a work-around.
Why hasn't the checkin-needed keyword been removed?
done.
Keywords: checkin-needed
Thank you.
I don't know if this is helpful or not, but I reproduced running the 2nd chunk of 10 for mochitest-plain on a 64bit Centos 5 machine with 
<http://hg.mozilla.org/mozilla-central/rev/e52f4987ec94> from 2010-12-03:

173 INFO TEST-START | /tests/content/events/test/test_bug574663.html
...
++DOMWINDOW == 14 (0x1a2e36c8) [serial = 25] [outer = 0x14fb5b50]
--DOMWINDOW == 13 (0x167f2f58) [serial = 23] [outer = 0x14fb5b50] [url = http://mochi.test:8888/tests/content/events/test/test_bug547996-2.xhtml]
...
==31421== Invalid read of size 8
==31421==    at 0x6DE80E6: js::MarkRangeConservatively(JSTracer*, unsigned long const*, unsigned long const*) (jsgc.cpp:712)
==31421==    by 0x6DE81AA: js::MarkThreadDataConservatively(JSTracer*, JSThreadData*) (jsgc.cpp:729)
==31421==    by 0x6DE82DE: js::MarkConservativeStackRoots(JSTracer*) (jsgc.cpp:762)
==31421==    by 0x6DE9D9B: js::MarkRuntime(JSTracer*) (jsgc.cpp:1610)
==31421==    by 0x6DEB0BF: MarkAndSweep(JSContext*, JSGCInvocationKind) (jsgc.cpp:2139)
==31421==    by 0x6DEBD3A: GCUntilDone(JSContext*, JSGCInvocationKind) (jsgc.cpp:2482)
==31421==    by 0x6DEBED8: js_GC(JSContext*, JSGCInvocationKind) (jsgc.cpp:2547)
==31421==    by 0x6D636EF: JS_GC (jsapi.cpp:2501)
==31421==    by 0x62BA52B: nsXPConnect::Collect() (nsXPConnect.cpp:405)
==31421==    by 0x62BA59A: nsXPConnect::GarbageCollect() (nsXPConnect.cpp:413)
==31421==    by 0x5D24FC4: nsJSContext::CC(nsICycleCollectorListener*) (nsJSEnvironment.cpp:3654)
==31421==    by 0x5D251D1: nsJSContext::IntervalCC() (nsJSEnvironment.cpp:3759)
==31421==  Address 0x7feff9f90 is just below the stack ptr.  To suppress, use: --workaround-gcc296-bugs=yes
==31421==
Since we have a workaround, I don't think we should block. Renominate if you feel differently.
blocking2.0: ? → -
status2.0: --- → wanted
Whiteboard: [approved-patches-landed]
Whiteboard: [approved-patches-landed] → [approved-patches-landed] not-ready
Assignee: igor → general
Assignee: general → nobody
Severity: normal → S3

Since there is a workaround and no updates in 13 years, marking as WONTFIX

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: