Talkback says 12.4% of trunk crashes are at [@ TimerThread::UpdateFilter]. Most comments for this crash indicate that it happened while exiting Firefox. This appears to be happening on all three major platforms (Win, Mac, Linux). Example stack: TimerThread::UpdateFilter() [xpcom/threads/TimerThread.cpp, line 197] TimerThread::UpdateFilter() [xpcom/threads/TimerThread.cpp, line 183] handleTimerEvent() [xpcom/threads/nsTimerImpl.cpp, line 470] PL_HandleEvent() [xpcom/threads/plevent.c, line 689] PL_ProcessPendingEvents() [xpcom/threads/plevent.c, line 623] nsEventQueueImpl::ProcessPendingEvents() [xpcom/threads/nsEventQueue.cpp, line 423] NS_ShutdownXPCOM_P() [xpcom/build/nsXPComInit.cpp, line 830] ScopedXPCOMStartup::~ScopedXPCOMStartup() [toolkit/xre/nsAppRunner.cpp, line 557] XRE_main() [toolkit/xre/nsAppRunner.cpp, line 2403] _start() start()

Ugh. I changed the shutdown sequence recently so that the timer thread is joined earlier in the shutdown sequence: I wonder if we're processing timer events after the timerthread expects. The line number in nsXPComInit.cpp is bogus, and even the top of the stack is suspect, but I suspect it's crashing here: http://lxr.mozilla.org/mozilla/source/xpcom/threads/nsTimerImpl.cpp#394 Called through here: http://lxr.mozilla.org/mozilla/source/xpcom/build/nsXPComInit.cpp#707 or #715 We should probably just null-check gThread there. I don't suppose there's a way to reproduce this reliably? Since it's timing-related probably not.

hmm... yeah, nsTimerImpl should protect itself against a shutdown timer thread.

Patch landed on trunk. Jesse, could you please verify that this fixes the topcrash?

Sure, I can look at Talkback again in a few days to see whether the topcrash went away.

I can verify that this is fixed based on Talkback data -- there are no crashes [@ TimerThread::UpdateFilter] recorded for March 22 and later builds.

Thanks!