Closed
Bug 608526
Opened 14 years ago
Closed 7 months ago
crash: Assertion failure: thread->data.nativeStackBase == GetNativeStackBase(), at js/src/jscntxt.cpp:645
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bjacob, Unassigned)
References
Details
(Whiteboard: [approved-patches-landed] not-ready)
Attachments
(6 files, 4 obsolete files)
5.50 KB,
text/plain
|
Details | |
3.21 KB,
patch
|
Details | Diff | Splinter Review | |
45.31 KB,
text/plain
|
Details | |
31.48 KB,
text/plain
|
Details | |
10.00 KB,
application/x-tar
|
Details | |
1018 bytes,
patch
|
jimb
:
review+
sayrer
:
approval2.0+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•14 years ago
|
Comment 1•14 years ago
|
||
Benoit, do you have the Java plugin installed? See bug 607146 (thanks to sayrer for pointing it out -- dup if you can). /be
Reporter | ||
Comment 2•14 years ago
|
||
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
Comment 3•14 years ago
|
||
do you have a breakpad report? That would show the loaded modules.
Reporter | ||
Comment 4•14 years ago
|
||
How could I generate such a report? (it's not getting automatically generated, it's just crashing here.)
Reporter | ||
Comment 5•14 years ago
|
||
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.
Reporter | ||
Comment 6•14 years ago
|
||
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
Reporter | ||
Comment 7•14 years ago
|
||
in previous comment, please read mochitest-plain (missing n)
blocking2.0: --- → ?
Reporter | ||
Comment 8•14 years ago
|
||
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.
Reporter | ||
Updated•14 years 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
Reporter | ||
Comment 9•14 years ago
|
||
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
Comment 10•14 years ago
|
||
Can't repro on my x64/Linux box. What distro/version?
Reporter | ||
Comment 11•14 years ago
|
||
This is on Fedora 13, x86-64.
Reporter | ||
Comment 12•14 years ago
|
||
By the way, my mozconfig has disable-jemalloc and enable-valgrind.
Comment 15•14 years ago
|
||
I am also seeing this, but crashing on launch of a newly built firefox.
Comment 16•14 years ago
|
||
adding my backtrace - this is on 32 bit ubuntu
Reporter | ||
Comment 17•14 years ago
|
||
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!
Reporter | ||
Comment 18•14 years ago
|
||
I also checked that the pthread_t object in GetNativeStackBaseImpl() is really always the same.
Reporter | ||
Comment 19•14 years ago
|
||
Valgrind doesn't report any error, so it shouldn't be a heap corruption.
Reporter | ||
Comment 20•14 years ago
|
||
To be clear: when run under valgrind, I don't get any crash or error at all.
Comment 21•14 years ago
|
||
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.
Comment 22•14 years ago
|
||
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
Reporter | ||
Comment 23•14 years ago
|
||
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
Reporter | ||
Comment 24•14 years ago
|
||
Comment 25•14 years ago
|
||
(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.
Comment 26•14 years ago
|
||
(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)
Comment 27•14 years ago
|
||
> 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.
Reporter | ||
Comment 28•14 years ago
|
||
Sent strace log privately to Julian as he tells me this could contain private information.
Comment 29•14 years ago
|
||
(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.
Comment 30•14 years ago
|
||
(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.
Reporter | ||
Comment 31•14 years ago
|
||
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) ?
Comment 32•14 years ago
|
||
> 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)
Comment 33•14 years ago
|
||
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.
Comment 34•14 years ago
|
||
(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
Comment 35•14 years ago
|
||
(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?
Comment 36•14 years ago
|
||
(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).
Reporter | ||
Comment 37•14 years ago
|
||
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...
Reporter | ||
Comment 38•14 years ago
|
||
Generated by: git log --name-only glibc-2.12..glibc-2.12.1
Reporter | ||
Comment 39•14 years ago
|
||
Generated by: git log -p glibc-2.12..glibc-2.12.1 Compressed with xz.
Reporter | ||
Comment 40•14 years ago
|
||
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.
Reporter | ||
Comment 41•14 years ago
|
||
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.
Reporter | ||
Comment 42•14 years ago
|
||
(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.
Comment 43•14 years ago
|
||
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
Comment 44•14 years ago
|
||
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);
Reporter | ||
Comment 45•14 years ago
|
||
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.
Comment 46•14 years ago
|
||
(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
Reporter | ||
Comment 47•14 years ago
|
||
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.
Reporter | ||
Comment 48•14 years ago
|
||
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
Comment 49•14 years ago
|
||
glibc bug filed at http://sourceware.org/bugzilla/show_bug.cgi?id=12225
Comment 50•14 years ago
|
||
(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?
Reporter | ||
Comment 51•14 years ago
|
||
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
Comment 52•14 years ago
|
||
(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.
Reporter | ||
Comment 53•14 years ago
|
||
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?
Comment 54•14 years ago
|
||
(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.
Comment 55•14 years ago
|
||
(In reply to comment #54) > no code running on them Sorry, by this I meant an empty stack, not that the thread is suspended.
Comment 57•14 years ago
|
||
(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.
Comment 58•14 years ago
|
||
(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!).
Reporter | ||
Comment 59•14 years ago
|
||
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.
Comment 60•14 years ago
|
||
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
Reporter | ||
Updated•14 years ago
|
Attachment #491177 -
Attachment is obsolete: true
Reporter | ||
Updated•14 years ago
|
Attachment #491178 -
Attachment is obsolete: true
Comment 61•14 years ago
|
||
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.
Reporter | ||
Comment 62•14 years ago
|
||
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.
Comment 63•14 years ago
|
||
(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.
Comment 64•14 years ago
|
||
(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.
Comment 65•14 years ago
|
||
Yes, the patch fixes all the crashes I experience.
Comment 66•14 years ago
|
||
Attachment #492229 -
Attachment is obsolete: true
Attachment #492617 -
Flags: review?(jimb)
Updated•14 years ago
|
Attachment #492617 -
Flags: review?(jimb) → review+
Updated•14 years ago
|
Keywords: checkin-needed
Reporter | ||
Updated•14 years ago
|
Attachment #492617 -
Flags: approval2.0?
Updated•14 years ago
|
Attachment #492617 -
Flags: approval2.0? → approval2.0+
Reporter | ||
Comment 67•14 years ago
|
||
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.
Comment 68•14 years ago
|
||
Why hasn't the checkin-needed keyword been removed?
Comment 70•14 years ago
|
||
Thank you.
Comment 71•14 years ago
|
||
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==
Comment 72•14 years ago
|
||
Since we have a workaround, I don't think we should block. Renominate if you feel differently.
Updated•14 years ago
|
Whiteboard: [approved-patches-landed]
Updated•13 years ago
|
Whiteboard: [approved-patches-landed] → [approved-patches-landed] not-ready
Updated•12 years ago
|
Assignee: igor → general
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•2 years ago
|
Severity: normal → S3
Comment 73•7 months ago
|
||
Since there is a workaround and no updates in 13 years, marking as WONTFIX
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•