This bug was filed from the Socorro interface and is report bp-5ed9afbd-3dc9-4132-9d27-626b70170930. ============================================================= Crashing Thread (7), Name: Socket Thread Frame Module Signature Source 0 xul.dll mozilla::EventQueue::`scalar deleting destructor'(unsigned int) xpcom/threads/nsThreadPool.cpp:61 1 xul.dll mozilla::psm::StopSSLServerCertVerificationThreads() security/manager/ssl/SSLServerCertVerification.cpp:198 2 xul.dll mozilla::net::nsSocketTransportService::Run() netwerk/base/nsSocketTransportService2.cpp:1068 3 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1039 4 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/threads/nsThreadUtils.cpp:521 5 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:338 6 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:319 7 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:299 8 xul.dll nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:427 9 nss3.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 10 nss3.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:95 11 ucrtbase.dll _o__CIpow 12 kernel32.dll BaseThreadInitThunk 13 mozglue.dll patched_BaseThreadInitThunk mozglue/build/WindowsDllBlocklist.cpp:824 14 ntdll.dll __RtlUserThreadStart 15 ntdll.dll _RtlUserThreadStart crashes during shutdown with this signature are newly showing up in 57 - so far only from 32bit firefox versions on windows 7 & 8 and all with "MOZ_RELEASE_ASSERT(IsEmpty())". the mejority of these crashes go through mozilla::psm::StopSSLServerCertVerificationThreads() in the stack, a few of them also through mozilla::dom::indexedDB::`anonymous namespace'::QuotaClient::ShutdownWorkThreads.
Hi JC, The backtrace is in the PSM module. Could you find someone to investigate this bug?
Thanks, Ethan. Adding Franziskus and David -- David: Can you dig into this this morning?
Flags: needinfo?(jjones) → needinfo?(dkeeler)
From what I can tell, necko is shutting down the cert verification thread pool. The assertion that's failing is that the thread pool's event queue's queue isn't empty. This doesn't make much sense because we just shut it down (and indeed, there aren't any ssl verification threads in the stack traces) and necko is in shutdown so it shouldn't be possible for it to be dispatching events to the nonexistent cert verification thread pool. Looks like bug 1382922 added this release assertion, but this behavior may have been present before then. Anyway, needinfo to :billm in the hopes that he might have some ideas.
Flags: needinfo?(dkeeler) → needinfo?(wmccloskey)
I think this is a preexisting problem. nsThreadPool uses its own event queue, different from the event queue of any of the threads in the pool. A normal nsThread will ensure that all events are processed before it shuts down. It looks like nsThreadPool has no such protection. We should probably add something to do that. I think the only change with bug 1382922 was to make this a release assertion. It might be a good idea to turn this back to a DEBUG assertion. I'm not sure we'll have time to fix it in the near future.
Component: General → XPCOM
Lets fix the assert for 57.
See comment 4.
Assignee: nobody → wmccloskey
Attachment #8917180 - Flags: review?(nfroyd)
Attachment #8917180 - Flags: review?(nfroyd) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/fb8794293bc6 Make Queue emptiness assertion DEBUG-only (r=froydnj)
New crash in 57, please request Beta approval when you get a chance.
Comment on attachment 8917180 [details] [diff] [review] patch Approval Request Comment [Feature/Bug causing the regression]: bug 1382922 [User impact if declined]: Crashes [Is this code covered by automated tests?]: Yes [Has the fix been verified in Nightly?]: No [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: Switching asserts from release mode to debug mode isn't going to impact anything. [String changes made/needed]: None.
Attachment #8917180 - Flags: approval-mozilla-beta?
Comment on attachment 8917180 [details] [diff] [review] patch debug assert is better, Beta57+
Attachment #8917180 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Nathan Froyd [:froydnj] from comment #10) > [Is this code covered by automated tests?]: Yes > [Has the fix been verified in Nightly?]: No > [Needs manual test from QE? If yes, steps to reproduce]: No Setting qe-verify- based on Nathan's assessment on manual testing and the fact that this fix has automated coverage.
You need to log in before you can comment on or make changes to this bug.