Closed
Bug 935846
Opened 11 years ago
Closed 10 years ago
Failure of CallCreateInstance in DOMGCSliceCallback
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: billm, Assigned: smaug)
Details
Attachments
(1 file, 1 obsolete file)
1.75 KB,
patch
|
romaxa
:
review+
|
Details | Diff | Splinter Review |
Luke got a crash with this stack trace recently. sFullGCTimer was NULL. #5 <signal handler called> #6 0x00007f7ff9756525 in DOMGCSliceCallback (aRt=0x7f7fe970d000, aProgress=JS::GC_CYCLE_END, aDesc=...) at /moz/mi/dom/base/nsJSEnvironment.cpp:2546 #7 0x00007f7ffbd076b1 in js::gcstats::Statistics::endSlice (this=0x7f7fe970d5a0) at /moz/mi/js/src/gc/Statistics.cpp:611 #8 0x00007f7ffbdc7143 in js::gcstats::AutoGCSlice::~AutoGCSlice (this=0x7fff6dae5850, __in_chrg=<optimized out>) at /moz/mi/js/src/gc/Statistics.h:186 #9 0x00007f7ffbdc19c1 in Collect (rt=0x7f7fe970d000, incremental=false, budget=0, gckind=js::GC_NORMAL, reason=JS::gcreason::SHUTDOWN_CC) at /moz/mi/js/src/jsgc.cpp:4769 #10 0x00007f7ffbdc1a16 in js::GC (rt=0x7f7fe970d000, gckind=js::GC_NORMAL, reason=JS::gcreason::SHUTDOWN_CC) at /moz/mi/js/src/jsgc.cpp:4775 #11 0x00007f7ffbda176b in JS::GCForReason (rt=0x7f7fe970d000, reason=JS::gcreason::SHUTDOWN_CC) at /moz/mi/js/src/jsfriendapi.cpp:192 #12 0x00007f7ffacde667 in mozilla::CycleCollectedJSRuntime::Collect (this=0x7f7feaf23000, aReason=51) at /moz/mi/xpcom/base/CycleCollectedJSRuntime.cpp:942 #13 0x00007f7fface589c in nsCycleCollector::FixGrayBits (this=0x7f7feaf7c000, aForceGC=true) at /moz/mi/xpcom/base/nsCycleCollector.cpp:2595 #14 0x00007f7fface5fe1 in nsCycleCollector::BeginCollection (this=0x7f7feaf7c000, aCCType=ShutdownCC, aManualListener=0x0) at /moz/mi/xpcom/base/nsCycleCollector.cpp:2755 #15 0x00007f7fface5c0d in nsCycleCollector::Collect (this=0x7f7feaf7c000, aCCType=ShutdownCC, aWhiteNodes=0x7fff6dae5b00, aResults=0x0, aManualListener=0x0) at /moz/mi/xpcom/base/nsCycleCollector.cpp:2687 #16 0x00007f7fface5b64 in nsCycleCollector::ShutdownCollect (this=0x7f7feaf7c000) at /moz/mi/xpcom/base/nsCycleCollector.cpp:2667 #17 0x00007f7fface6277 in nsCycleCollector::Shutdown (this=0x7f7feaf7c000) at /moz/mi/xpcom/base/nsCycleCollector.cpp:2810 #18 0x00007f7fface738e in nsCycleCollector_shutdown () at /moz/mi/xpcom/base/nsCycleCollector.cpp:3170 #19 0x00007f7ffac63f31 in mozilla::ShutdownXPCOM (servMgr=0x0) at /moz/mi/xpcom/build/nsXPComInit.cpp:753 #20 0x00007f7ffac63a0c in NS_ShutdownXPCOM (servMgr=0x0) at /moz/mi/xpcom/build/nsXPComInit.cpp:618 #21 0x00007f7ff8773f3f in XRE_TermEmbedding () at /moz/mi/toolkit/xre/nsEmbedFunctions.cpp:199 #22 0x00007f7ffa342cee in mozilla::ipc::ScopedXREEmbed::Stop (this=0x7f7fed4237e8) at /moz/mi/ipc/glue/ScopedXREEmbed.cpp:110 #23 0x00007f7ffa2e3ffe in mozilla::dom::ContentProcess::CleanUp (this=0x7f7fed423400) at /moz/mi/dom/ipc/ContentProcess.cpp:37 #24 0x00007f7ff8774630 in XRE_InitChildProcess (aArgc=3, aArgv=0x7fff6daeef88, aProcess=GeckoProcessType_Content) at /moz/mi/toolkit/xre/nsEmbedFunctions.cpp:555 #25 0x0000000000403754 in main (argc=4, argv=0x7fff6daeef88) at /moz/mi/ipc/app/MozillaRuntimeMain.cpp:137 It sounds like it happened during shutdown, which maybe makes CallCreateInstance fail. However, we already are checking the sShuttingDown flag. Luke was using an e10s build. Maybe we don't fire the quit-application observer if we're in a content process?
You can see from the stack that we're in XPCOM and cycle collector shutdown. The CC shuts down at the very end of shutdown, after the component manager is torn down, so you definitely can't CallCreateInstance at this point. I don't know why you would expect us to fire quit-application in a content process, especially if the app is not quitting but merely shutting down an unnecessary content process. Sounds like you should be using one of the XPCOM shutdown notifications.
Component: DOM: Core & HTML → XPCOM
Comment 2•10 years ago
|
||
I'm able to reproduce this 100% time with Embedlite environment: http://pastebin.mozilla.org/6847893 it dies all the time during shutdown
Assignee | ||
Comment 3•10 years ago
|
||
Sounds like we should use xpcom-shutdown.
Assignee | ||
Comment 4•10 years ago
|
||
Oh, I see... we want possibly observe both quit-application and xpcom-shutdown.
Assignee | ||
Comment 5•10 years ago
|
||
...since quit-application observing was added in bug 822849, and observing something which happens before xpcom-shutdown was the whole point of that bug. But for content processes, xpcom-shutdown should work.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → bugs
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8509406 -
Flags: review?(romaxa)
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8509406 [details] [diff] [review] v1 Whoever reviews this first.
Attachment #8509406 -
Flags: review?(continuation)
Comment 8•10 years ago
|
||
Comment on attachment 8509406 [details] [diff] [review] v1 >- } else if (!nsCRT::strcmp(aTopic, "quit-application")) { >+ } else if (!nsCRT::strcmp(aTopic, "quit-application") || >+ !nsCRT::strcmp(aTopic, "xpcom-shutdown")) { use NS_XPCOM_SHUTDOWN_OBSERVER_ID instead of "xpcom-shutdown" and yep, this fixes the problem
Attachment #8509406 -
Flags: review?(romaxa) → review+
Assignee | ||
Comment 9•10 years ago
|
||
Attachment #8509406 -
Attachment is obsolete: true
Attachment #8509406 -
Flags: review?(continuation)
Updated•10 years ago
|
Attachment #8509567 -
Flags: review+
Assignee | ||
Comment 10•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/1fe040127ebd
Comment 11•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1fe040127ebd
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•