There some hangs in: 0 ntdll.dll NtWaitForSingleObject 1 kernelbase.dll WaitForSingleObjectEx 2 nss3.dll PR_MD_WAIT_CV nsprpub/pr/src/md/windows/w95cv.c:248 3 nss3.dll PR_WaitCondVar nsprpub/pr/src/threads/combined/prucv.c:172 4 nss3.dll PR_WaitCondVar nsprpub/pr/src/threads/combined/prucv.c:525 5 xul.dll mozilla::CondVar::Wait(unsigned int) obj-firefox/dist/include/mozilla/CondVar.h:79 6 xul.dll nsEventQueue::GetEvent(bool, nsIRunnable**, mozilla::BaseAutoLock<mozilla::Mutex>&) xpcom/threads/nsEventQueue.cpp:57 7 xul.dll nsThread::nsChainedEventQueue::GetEvent(bool, nsIRunnable**, mozilla::BaseAutoLock<mozilla::Mutex>&) xpcom/threads/nsThread.cpp:788 8 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1203 9 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:381 10 xul.dll mozilla::dom::XMLHttpRequestMainThread::SendInternal(mozilla::dom::XMLHttpRequestMainThread::RequestBodyBase const*) dom/xhr/XMLHttpRequestMainThread.cpp:3006 11 xul.dll mozilla::dom::XMLHttpRequestMainThread::Send(JSContext*, nsAString_internal const&, mozilla::ErrorResult&) dom/xhr/XMLHttpRequestMainThread.h:383 12 xul.dll mozilla::dom::XMLHttpRequestBinding::send obj-firefox/dom/bindings/XMLHttpRequestBinding.cpp:777 13 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp:457 14 xul.dll Interpret js/src/vm/Interpreter.cpp:2919 15 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:403 16 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp:475 17 xul.dll js::jit::DoCallFallback js/src/jit/BaselineIC.cpp:4733 18 @0x38bac3bb42c 19 xul.dll js::NewObjectWithClassProtoCommon(js::ExclusiveContext*, js::Class const*, JS::Handle<JSObject*>, js::gc::AllocKind, js::NewObjectKind) js/src/jsobj.cpp:781 20 @0x547e1e8d2f 21 xul.dll xul.dll@0x6f6e0b 22 xul.dll js::jit::EnterBaselineMethod(JSContext*, js::RunState&) js/src/jit/BaselineJIT.cpp:195 23 xul.dll Interpret js/src/vm/Interpreter.cpp:2964 24 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:403 25 xul.dll js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp:475 26 xul.dll js::jit::DoCallFallback js/src/jit/BaselineIC.cpp:4733 27 @0x38bac3bb42c

https://crash-stats.mozilla.com/report/index/98de7bba-56ec-498d-a858-8183c2161220 https://crash-stats.mozilla.com/report/index/98c74c7d-39f7-4c50-b3a5-14f532161220 https://crash-stats.mozilla.com/report/index/c4edcf5c-c969-4dec-9e83-a5b812161217 https://crash-stats.mozilla.com/report/index/146d44d2-f0de-4d7d-add6-b5bf52161217

Hi Shawn, could you please help take a look and see what's up here? Is this a regression? I am asking because it appears on crash-stats since 53.

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #2) > Hi Shawn, could you please help take a look and see what's up here? > > Is this a regression? I am asking because it appears on crash-stats since 53. Sure. I will check.

See also: bug 1323084

Bug 1323084 Comment 2 It seems similar crashes happen in different cases. And I'm not sure how to reproduce the crash (I've tried to run xhr tests many times).

(In reply to Shawn Huang [:shawnjohnjr] from comment #5) > Bug 1323084 Comment 2 > It seems similar crashes happen in different cases. They are not similar. There are many different causes for the crashes in bug 1323084 comment 2, in my opinion. Here, mFlagSyncLooping should have been set to false. What I can see form code it is set to false when xhr gets aborted. Can we cancel xhr when we know that we are in shutdown or something?

It seems in bug 1324820, the similar problem also occurs but it gets resolved from necko. But the code path is different.

I can now easily reproduce now followed by the steps to reproduce in bug 1324820, however, topic NS_XPCOM_SHUTDOWN_OBSERVER_ID will be received after checking mFlagSyncLooping. It's too late to set mFlagSyncLooping to false.

(In reply to Shawn Huang [:shawnjohnjr] from comment #9) > I can now easily reproduce now followed by the steps to reproduce in bug > 1324820, however, topic NS_XPCOM_SHUTDOWN_OBSERVER_ID will be received after > checking mFlagSyncLooping. It's too late to set mFlagSyncLooping to false. I should check quit-application instead of xpcom-shutdown.

Interesting, after running test a couple of times, I added observer and watch the topic "quit-application", but I found that one of XMLHttpRequestMainThread object constructs after "quit-application" received, so Observe() won't run.

(gdb) call DumpJSStack() 0 send(d = [object Object], e = [function]) ["https://abs.twimg.com/c/swift/en/init.34b94d9e514e518c134065b0d48da0f0f71d4e1b.js":355] this = [object Object] 1 ajax(a = undefined) ["https://abs.twimg.com/c/swift/en/init.34b94d9e514e518c134065b0d48da0f0f71d4e1b.js":339] this = function (a,b){return new jQuery.fn.init(a,b)} 2 flush(a = "{"internal_referer":null,"client_version":"macaw-swift","user_id":0,"items":[{"moments_details":{"moment_id":"810878086774456320"}}],"event_namespace":{"client":"web","page":"moments","section":"capsule","action":"show"},"triggered_on":1484118275303,"format_version":2,"_category_":"client_event"},{"product":"webclient","description":"stats:ajax:perf:partner_id_sync:success","duration_ms":1523,"start_time_ms":1484118274970,"metadata":"{\"url\":\"https://analytics.twitter.com/tpm/p\",\"browser\":{\"name\":\"mozilla\",\"version\":\"53.0\"},\"response_size\":2}","_category_":"perftown"}", b = true) ["https://abs.twimg.com/c/swift/en/init.34b94d9e514e518c134065b0d48da0f0f71d4e1b.js":518] this = [object Object] 3 registerEventHandlers/<([object Object]) ["https://abs.twimg.com/c/swift/en/init.34b94d9e514e518c134065b0d48da0f0f71d4e1b.js":518] this = [object Window] 4 dispatch(a = [object Object]) ["https://abs.twimg.com/c/swift/en/init.34b94d9e514e518c134065b0d48da0f0f71d4e1b.js":218] this = [object Window] 5 add/r.handle(b = [object Event]) ["https://abs.twimg.com/c/swift/en/init.34b94d9e514e518c134065b0d48da0f0f71d4e1b.js":210] this = [object Window]

By the way, I found in "non-e10s" build, after entering the loop for the next event, onStopRequest will be called. But in e10s build, I did not see onStopRequest get called. #0 mozilla::dom::XMLHttpRequestMainThread::OnStopRequest (this=0x7fffaa9bfc00, request=0x7fffabfb2858, ctxt=0x0, status=-2142568446) at /home/shawnjohnjr/code/mozilla-inbound/dom/xhr/XMLHttpRequestMainThread.cpp:2100 #1 0x00007fffe851e49a in nsCORSListenerProxy::OnStopRequest (this=0x7fffc945f460, aRequest=0x7fffabfb2858, aContext=0x0, aStatusCode=-2142568446) at /home/shawnjohnjr/code/mozilla-inbound/netwerk/protocol/http/nsCORSListenerProxy.cpp:642 #2 0x00007fffe853fff8 in mozilla::net::nsHttpChannel::OnStopRequest (this=0x7fffabfb2800, request=<optimized out>, ctxt=<optimized out>, status=-2142568446) at /home/shawnjohnjr/code/mozilla-inbound/netwerk/protocol/http/nsHttpChannel.cpp:6849 #3 0x00007fffe82736a4 in nsInputStreamPump::OnStateStop (this=this@entry=0x7fffbabc5040) at /home/shawnjohnjr/code/mozilla-inbound/netwerk/base/nsInputStreamPump.cpp:714 #4 0x00007fffe8275e75 in nsInputStreamPump::OnInputStreamReady (this=0x7fffbabc5040, stream=<optimized out>) at /home/shawnjohnjr/code/mozilla-inbound/netwerk/base/nsInputStreamPump.cpp:433 #5 0x00007fffe81b5175 in nsInputStreamReadyEvent::Run (this=0x7fffabde2d30) at /home/shawnjohnjr/code/mozilla-inbound/xpcom/io/nsStreamUtils.cpp:95 #6 0x00007fffe81ccee0 in nsThread::ProcessNextEvent (this=0x7fffe5b20460, aMayWait=<optimized out>, aResult=0x7fffffffc447) at /home/shawnjohnjr/code/mozilla-inbound/xpcom/threads/nsThread.cpp:1213

Based on Comment 13, i think we should figure out why onStopRequest() get called in non-e10s build. And I don't know why xpcom-shutdown event always received after timeout.

This seems to be he same bug as 1324820.

I've discussed with Thomas, I think fixing this bug from necko is more accurate.