Closed Bug 963474 Opened 10 years ago Closed 10 years ago

Assertion failure and crash: rc != 0 (destroyed timer off its target thread!), at ../../../xpcom/threads/TimerThread.cpp:259

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
29 Branch
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 881413
Tracking Flags:
Tracking Status
firefox29 + fixed

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: assertion, crash, regression) 

Version=29.0a1
BuildID=20131219013406
SourceRepository=http://hg.mozilla.org/mozilla-central
SourceStamp=5c7fa2bfea8b

A debug build of Firefox Nightly shows an assertion and crashes on shutdown when I run it via Mozmill on OS X:

Last lines of the console log:

[90258] WARNING: cannot post event if not initialized: file ../../../../netwerk/protocol/http/nsHttpConnectionMgr.cpp, line 170
[90258] WARNING: cannot post event if not initialized: file ../../../../netwerk/protocol/http/nsHttpConnectionMgr.cpp, line 170
[90258] WARNING: An event was posted to a thread that will never run it (rejected): file ../../../xpcom/threads/nsThread.cpp, line 367
Assertion failure: rc != 0 (destroyed timer off its target thread!), at ../../../xpcom/threads/TimerThread.cpp:259

The Apple crash reporter comes up and shows:

Crashed Thread:  12  Timer

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000100000000-0000000100004000 [   16K] r-x/rwx SM=COW  /Volumes/VOLUME/*/FirefoxNightlyDebug.app/Contents/MacOS/firefox

Thread 12 Crashed:: Timer
0   XUL                           	0x00000001010966b6 0x101000000 + 616118
1   XUL                           	0x000000010109af22 0x101000000 + 634658
2   XUL                           	0x00000001010122f3 0x101000000 + 74483
3   XUL                           	0x000000010137c2a6 0x101000000 + 3654310
4   XUL                           	0x0000000101358ce6 0x101000000 + 3509478
5   XUL                           	0x0000000101099c73 0x101000000 + 629875
6   libnss3.dylib                 	0x0000000100526987 0x100300000 + 2255239
7   libsystem_pthread.dylib       	0x00007fff8db07899 _pthread_body + 138
8   libsystem_pthread.dylib       	0x00007fff8db0772a _pthread_start + 137
9   libsystem_pthread.dylib       	0x00007fff8db0bfc9 thread_start + 13

Not sure if this is somewhat related to networking. So filing as general bug for now. It might be related to bugs we have seen on TPBL like bug 881413 or bug 941751.

This is a regression started around Dec 19th. I will try to get more information about it.
(In reply to Henrik Skupin (:whimboo) from comment #0)
> Version=29.0a1
> BuildID=20131219013406
> SourceRepository=http://hg.mozilla.org/mozilla-central
> SourceStamp=5c7fa2bfea8b
> 
> A debug build of Firefox Nightly shows an assertion and crashes on shutdown
> when I run it via Mozmill on OS X:
> 
> Last lines of the console log:
> 
> [90258] WARNING: cannot post event if not initialized: file
> ../../../../netwerk/protocol/http/nsHttpConnectionMgr.cpp, line 170
> [90258] WARNING: cannot post event if not initialized: file
> ../../../../netwerk/protocol/http/nsHttpConnectionMgr.cpp, line 170
> [90258] WARNING: An event was posted to a thread that will never run it
> (rejected): file ../../../xpcom/threads/nsThread.cpp, line 367
> Assertion failure: rc != 0 (destroyed timer off its target thread!), at
> ../../../xpcom/threads/TimerThread.cpp:259
> 
> The Apple crash reporter comes up and shows:
> 
> Crashed Thread:  12  Timer
> 
> Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
> 
> VM Regions Near 0:
> --> 
>     __TEXT                 0000000100000000-0000000100004000 [   16K]
> r-x/rwx SM=COW 
> /Volumes/VOLUME/*/FirefoxNightlyDebug.app/Contents/MacOS/firefox
> 
> Thread 12 Crashed:: Timer
> 0   XUL                           	0x00000001010966b6 0x101000000 + 616118
> 1   XUL                           	0x000000010109af22 0x101000000 + 634658
> 2   XUL                           	0x00000001010122f3 0x101000000 + 74483
> 3   XUL                           	0x000000010137c2a6 0x101000000 + 3654310
> 4   XUL                           	0x0000000101358ce6 0x101000000 + 3509478
> 5   XUL                           	0x0000000101099c73 0x101000000 + 629875
> 6   libnss3.dylib                 	0x0000000100526987 0x100300000 + 2255239
> 7   libsystem_pthread.dylib       	0x00007fff8db07899 _pthread_body + 138
> 8   libsystem_pthread.dylib       	0x00007fff8db0772a _pthread_start + 137
> 9   libsystem_pthread.dylib       	0x00007fff8db0bfc9 thread_start + 13
> 
> Not sure if this is somewhat related to networking. So filing as general bug
> for now. It might be related to bugs we have seen on TPBL like bug 881413 or
> bug 941751.
> 
> This is a regression started around Dec 19th. I will try to get more
> information about it.

We will take that offer
Anthony, Just wanted to make sure this is on your radar
Flags: needinfo?(anthony.s.hughes)
CCing Juan Becerra since he is QA lead for Firefox 29.
Flags: needinfo?(anthony.s.hughes)
I was not able to get closer to this problem yet. It's very hard to get a regression range here. Once we have released Mozmill 2.0.4 I will have a bit more time for further checks here. This will happen beginning of next week.
(In reply to Henrik Skupin (:whimboo) from comment #4)
> I was not able to get closer to this problem yet. It's very hard to get a
> regression range here. Once we have released Mozmill 2.0.4 I will have a bit
> more time for further checks here. This will happen beginning of next week.

Do you think this still needs tracking since it is nominated?
So I finally found the time to check for a regression range.

PASS: 20131219013406 (http://hg.mozilla.org/mozilla-central/5c7fa2bfea8b)
FAIL: 20131219125132 (http://hg.mozilla.org/mozilla-central/95588faa95b5)

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c7fa2bfea8b&tochange=95588faa95b5

There is a singly changeset only here. But checking the code on bug 952183 I'm not pretty sure about. Bill, can you please have a look? Is there a chance to figure out which kind of timer this is? Sadly I cannot use a self-build debug build because it is too slow when get run through mozmill.
Flags: needinfo?(wmccloskey)
I wonder if this could also be a problem in Mozmill given that we make use of the component loader:
https://github.com/mozilla/mozmill/blob/master/mozmill/mozmill/extension/resource/modules/frame.js#L570
There's a very similar intermittent crash in a debug build in bug 881413, so maybe some information can be gotten from those logs.
Blocks: 881413
Hm, that one exists since 2013-06-10 while this regression started for me on 2013-12-19. So both might be different crashes.
Sorry, I can't tell what's going on. I don't really know anything about the timer code. It seems like it's probably been failing before my patch though.
Flags: needinfo?(wmccloskey)
Bill, you were correct. I somehow made a mistake with the last regression test. I copied the pushlog from the other half of the remaining list. So the actual regressor has to be in this range:

PASS: 20131219012911 (http://hg.mozilla.org/mozilla-central/35c6a9cd23b0)
FAIL: 20131219013406 (http://hg.mozilla.org/mozilla-central/5c7fa2bfea8b)

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35c6a9cd23b0&tochange=5c7fa2bfea8b

So this is a merge from fxteam to mozilla-central done by Carsten. I might now have to dive deeper into tinderbox builds for that branch.
No longer blocks: 881413
Strangely the pushlog on fxteam does not really correlate to the changeset from above. Instead an earlier changeset which is not listed in the range above has been caused the assertion. I don't really understand this. Shouldn't those be identical between branches?
Keywords: crash
Keywords: assertion
Gavin - can you help Whimboo here with comment 12?  A regression range is still needed here.
Flags: needinfo?(gavin.sharp)
(In reply to Henrik Skupin (:whimboo) [away 02/24 - 02/28] from comment #12)
> Strangely the pushlog on fxteam does not really correlate to the changeset
> from above. Instead an earlier changeset which is not listed in the range
> above has been caused the assertion.

Which changeset?
Flags: needinfo?(gavin.sharp)
Rather than trying to pin down the regression range, can you just attach in a debugger and dump the timer that's causing the issue here. Any time we hit this block is really a bug:

http://hg.mozilla.org/mozilla-central/annotate/1507f021ac93/xpcom/threads/TimerThread.cpp#l245

And so before the NS_RELEASE2 we really want to know timer->mCallbackType and timer->mCallback. If it's CALLBACK_TYPE_FUNC then we really want to know what function timer->mCallback.c is pointing to.
Flags: needinfo?(hskupin)
Also it would be helpful to see the stacks of all threads not just this one.
Henrik, any chance you could provide a patch for this in 29? We are going to build 29 beta 3 today.
Thanks
Is this still an issue with bug 881413 fixed?
I will not be able to provide a patch here, even the investigation will be hard given that I have Mavericks installed, and Mozmill doesn't support the new debugger yet. But I can check if I still see this problem later today. I will report back.
I checked the latest inbound debug tinderbox build and all looks fine for me. No more assertions reported and no crash happening. So it looks like that this is indeed a dupe of bug 881413.
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox28: unaffected → ---
status-firefox29: affected → fixed
Flags: needinfo?(hskupin)
Keywords: regressionwindow-wanted
Resolution: --- → DUPLICATE
See Also: → 1729964
You need to log in before you can comment on or make changes to this bug.