topcrash on exit [@ TimerThread::UpdateFilter]

VERIFIED FIXED in mozilla1.9alpha1

Status

()

defect
--
critical
VERIFIED FIXED
13 years ago
8 years ago

People

(Reporter: jruderman, Assigned: benjamin)

Tracking

({crash, topcrash})

Trunk
mozilla1.9alpha1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

Reporter

Description

13 years ago
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()
Reporter

Updated

13 years ago
Flags: blocking1.9a1?
Assignee

Comment 1

13 years ago
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.
Component: General → XPCOM
Product: Firefox → Core
QA Contact: general → xpcom
Target Milestone: --- → mozilla1.9alpha
Assignee

Updated

13 years ago
Blocks: 326491
Assignee

Updated

13 years ago
Assignee: nobody → benjamin

Comment 2

13 years ago
hmm... yeah, nsTimerImpl should protect itself against a shutdown timer thread.
Assignee

Comment 3

13 years ago
Attachment #215681 - Flags: review?(darin)

Updated

13 years ago
Attachment #215681 - Flags: review?(darin) → review+
Assignee

Comment 4

13 years ago
Patch landed on trunk. Jesse, could you please verify that this fixes the topcrash?
Assignee: benjamin → jruderman
Reporter

Comment 5

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

Comment 6

13 years ago
I can verify that this is fixed based on Talkback data -- there are no crashes [@ TimerThread::UpdateFilter] recorded for March 22 and later builds.
Assignee: jruderman → benjamin
Flags: blocking1.9a1?
Keywords: qawanted
Reporter

Updated

13 years ago
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Reporter

Updated

13 years ago
Status: RESOLVED → VERIFIED
Assignee

Comment 7

13 years ago
Thanks!
Crash Signature: [@ TimerThread::UpdateFilter]
You need to log in before you can comment on or make changes to this bug.