Closed Bug 935846 Opened 11 years ago Closed 10 years ago

Failure of CallCreateInstance in DOMGCSliceCallback

Categories

(Core :: XPCOM, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: billm, Assigned: smaug)

Details

Attachments

(1 file, 1 obsolete file)

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
I'm able to reproduce this 100% time with Embedlite environment:
http://pastebin.mozilla.org/6847893
it dies all the time during shutdown
Sounds like we should use xpcom-shutdown.
Oh, I see... we want possibly observe both quit-application and xpcom-shutdown.
...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: nobody → bugs
Attached patch v1 (obsolete) — Splinter Review
Attachment #8509406 - Flags: review?(romaxa)
Comment on attachment 8509406 [details] [diff] [review]
v1

Whoever reviews this first.
Attachment #8509406 - Flags: review?(continuation)
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+
Attached patch v2Splinter Review
Attachment #8509406 - Attachment is obsolete: true
Attachment #8509406 - Flags: review?(continuation)
Attachment #8509567 - Flags: review+
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.

Attachment

General

Created:
Updated:
Size: