Closed Bug 962846 Opened 7 years ago Closed 6 years ago

crash in mozalloc_abort(char const*) | Abort | NS_DebugBreak | GCGraphBuilder::DescribeRefCountedNode(unsigned int, char const*)


(Core :: DOM: Workers, defect)

Not set



Tracking Status
firefox26 --- unaffected
firefox27 --- unaffected
firefox28 + wontfix
firefox29 - unaffected
firefox30 --- unaffected


(Reporter: u279076, Unassigned)



(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-82a9d819-2f01-4a1f-bb07-318172140121.
0 	libmozalloc.dylib 	mozalloc_abort(char const*) 	/builds/slave/fx-team-osx64-0000000000000000/build/obj-firefox/x86_64/memory/mozalloc/../../../../memory/mozalloc/mozalloc_abort.cpp
1 	XUL 	Abort 	xpcom/base/nsDebugImpl.cpp
2 	XUL 	NS_DebugBreak 	xpcom/base/nsDebugImpl.cpp
3 	XUL 	GCGraphBuilder::DescribeRefCountedNode(unsigned int, char const*) 	xpcom/base/nsCycleCollector.cpp
4 	XUL 	nsDOMEventTargetHelper::cycleCollection::Traverse(void*, nsCycleCollectionTraversalCallback&) 	content/events/src/nsDOMEventTargetHelper.cpp
5 	XUL 	nsXHREventTarget::cycleCollection::Traverse(void*, nsCycleCollectionTraversalCallback&) 	content/base/src/nsXMLHttpRequest.cpp
6 	XUL 	mozilla::dom::workers::XMLHttpRequest::cycleCollection::Traverse(void*, nsCycleCollectionTraversalCallback&) 	dom/workers/XMLHttpRequest.cpp
7 	XUL 	GCGraphBuilder::Traverse(PtrInfo*) 	xpcom/base/nsCycleCollector.cpp
8 	XUL 	nsCycleCollector::MarkRoots(js::SliceBudget&) 	xpcom/base/nsCycleCollector.cpp
9 	XUL 	nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*) 	xpcom/base/nsCycleCollector.cpp
10 	XUL 	nsCycleCollector_collect(nsICycleCollectorListener*) 	xpcom/base/nsCycleCollector.cpp
11 	XUL 	Collect 	js/src/jsgc.cpp
12 	XUL 	js::DestroyContext(JSContext*, js::DestroyContextMode) 	js/src/jscntxt.cpp
13 	XUL 	(anonymous namespace)::WorkerThreadRunnable::Run() 	dom/workers/RuntimeService.cpp
14 	XUL 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
15 	XUL 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
16 	XUL 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
17 	libnss3.dylib 	_pt_root 	
18 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x1899 	
19 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x172a 	
20 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x5fc9 	
21 	libnss3.dylib 	null_signal_handler 	

More Reports:

This has recently risen to the #10 crash on Aurora and shows up as a startup crash. However it currently sits at #31 on Nightly and is extremely low volume on Beta and earlier. Looking at the 28-day graph it seems like this started to pick up on 2014-01-13 and peaked on 2014-01-18.

KaiRo, do you know how we might debug this further?
Flags: needinfo?(kairo)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #0)
> KaiRo, do you know how we might debug this further?

This is an abort, so do we have the same abort message for all of them (or a significant sample)? Do we have any useful correlations? URLs?
Flags: needinfo?(kairo)
(In reply to Robert Kaiser ( from comment #1)

> Do we have any useful URLs?
The top URLs are about:blank, about:home, and about:addons; perhaps not unsurprising since this is a startup crash. There are other URLs but they are extremely low volume (5 instances or less).

> Do we have any useful correlations?
There are no correlations whatsoever.

> Do we have the same abort message for all of them or a significant sample?
Most of them seem to have the message, "ABORT: cycle collector fault: file ../../../../xpcom/base/nsCycleCollector.cpp, line 1254"
Tim, could this bug be related or fixed by bug 956284? Comments on those crashes tell that it happens on shutdown. Also app notes for those crashes in the report show:

xpcom_runtime_abort([7763] ###!!! ABORT: cycle collector fault: file ../../../../xpcom/base/nsCycleCollector.cpp, line 1226)
Flags: needinfo?(ttaubert)
The stack looks exactly like bug 956284. I'd call this fixed.
Flags: needinfo?(ttaubert)
Thanks. I think we should wait until Monday and check crash stats again if the crashes with this stack are gone. Anthony, can you do this?
Flags: needinfo?(
Whiteboard: [fixed by bug 956284?]
(In reply to Henrik Skupin (:whimboo) from comment #5)
> Thanks. I think we should wait until Monday and check crash stats again if
> the crashes with this stack are gone. Anthony, can you do this?

Sure, I'll take a look at stats Monday morning.
Flags: needinfo?(
Keywords: verifyme
QA Contact:
This has dropped to #28 on Nightly and #22 on Aurora but has not disappeared altogether. I still see 5 crashes for Firefox 29.0a1 and 5 crashes on Firefox 28.0a2 from 2014-01-30 and onward. So while the topcrash nature of this bug may be resolved the crash has not.
0 reports for Firefox 30.0a1:*%29+|+Abort+|+NS_DebugBreak+|+GCGraphBuilder%3A%3ADescribeRefCountedNode%28unsigned+int%2C+char+const*%29&reason=&release_channels=&build_id=&process_type=any&hang_type=any

0 reports for Firefox 29.0a2:*%29+|+Abort+|+NS_DebugBreak+|+GCGraphBuilder%3A%3ADescribeRefCountedNode%28unsigned+int%2C+char+const*%29&reason=&release_channels=&build_id=&process_type=any&hang_type=any

5 reports for Firefox 28.0b1:*%29+|+Abort+|+NS_DebugBreak+|+GCGraphBuilder%3A%3ADescribeRefCountedNode%28unsigned+int%2C+char+const*%29&reason=&release_channels=&build_id=&process_type=any&hang_type=any

I think we can call this fixed given no volume on Firefox 29 and 30, and extremely low volume on Firefox 28.

Please reopen if you disagree.
Closed: 7 years ago
Resolution: --- → FIXED
Assignee: nobody → ttaubert
Depends on: 956284
Target Milestone: --- → mozilla29
Component: General → DOM: Workers
This failed again with Beta en-GB on osx 10.6 (mm-osx-106-1)
It failed after testPreferences_masterPassword, I checked the node for the last crash report so I found the one below.
I'm not sure yet if the fix from bug 956284 has to be merged in beta or if this crash could have a different cause.
As this was verified on Nightly and Aurora I will change the flag of 30 to verified and 28 to affected.
Jenkins log:
>15:02:22 TEST-START | restartTests/testPreferences_masterPassword/test1.js | testSetMasterPassword
>15:02:27 2014-02-18 15:18:54.146 firefox[7999:7e0b] invalid pixel format
>15:02:27 2014-02-18 15:18:54.147 firefox[7999:7e0b] invalid context
>15:02:27 2014-02-18 15:18:54.147 firefox[7999:7e0b] invalid pixel format
>15:02:27 2014-02-18 15:18:54.148 firefox[7999:7e0b] invalid context
>15:02:27 TEST-PASS | restartTests/testPreferences_masterPassword/test1.js | testSetMasterPassword
>15:02:27 TEST-START | restartTests/testPreferences_masterPassword/test1.js | teardownModule
>15:02:27 TEST-END | restartTests/testPreferences_masterPassword/test1.js | finished in 5593ms
>15:03:29 Fault in cycle collector: overflowing refcount (ptr: 0x10776c3d0)
>15:03:29 [7999] ###!!! ABORT: cycle collector fault: file /builds/slave/rel-m-beta-osx64_bld-000000000/build/xpcom/base/nsCycleCollector.cpp, line 1226
>15:03:29 [7999] ###!!! ABORT: cycle collector fault: file /builds/slave/rel-m-beta-osx64_bld-000000000/build/xpcom/base/nsCycleCollector.cpp, line 1226
>15:03:29 RESULTS | Passed: 27
>15:03:29 RESULTS | Failed: 0
>15:03:29 RESULTS | Skipped: 5
>15:03:32 Traceback (most recent call last):
>15:03:32   File "/Users/mozauto/jenkins/workspace/release-mozilla-beta_functional/mozmill-env-mac/python-lib/mozmill_automation/", line 349, in run
>15:03:32     self.run_tests()
>15:03:32   File "/Users/mozauto/jenkins/workspace/release-mozilla-beta_functional/mozmill-env-mac/python-lib/mozmill_automation/", line 573, in run_tests
>15:03:32     TestRun.run_tests(self)

Crash report:
Testrun report:
Robert and Anthony, can you both please check crashstats? Given that we haven't had a fix for that crash, I wonder what our situation really is across beta, aurora, and nightly. Are the latter two really not affected anymore?

I did a quick spot-check and I don't concur that it is fixed given that I see a crash with Firefox 29.0a2 (20140216040204): bp-825f5cb9-5093-456a-8d62-8d33d2140218. I do not see any crash report for Firefox 30.0a1.
Flags: needinfo?(kairo)
Flags: needinfo?(
Whiteboard: [fixed by bug 956284?]
I checked the ranking info and this does not show up at all in the top-300 Mac OSX reports for Firefox 27, 29, and 30. It shows up at #3 for Mac OSX crashes in Firefox 28 and #221 overall with 126 crashes in the last week. While this does not qualify as a topcrash overall it does qualify as a Mac-specific topcrash. I would also say that this was *not* fixed by bug 956284 considering that landed for Firefox 28 in Aurora.
Flags: needinfo?(kairo)
Flags: needinfo?(
Keywords: topcrash-mac
So something fixed it for 30.0a1 then? Or we might not have so much users who run that build, or are able to trigger that crash.
Nightly and Aurora have low ADI volume, and Mac is only a small percentage in volume overall, so I wouldn't trust that it doesn't occur on those channels if we haven't seen it in good volume there before.

That said, the closing sentence of comment #12 stands out: If this is still seen in Beta 28, we can be pretty sure it wasn't really fixed on Aurora 28.
Tim, do you have a chance to look at this bug in the next couple of days?
Target Milestone: mozilla29 → ---
I can't trigger the crash using the same approach as for bug 956284 (maybe they are not the same after all). We would need a somewhat reliable way to reproduce this.
Cosmin, can you please check for which tests this crash happened on our OS X machines? Probably we can somehow get it to reproduce.
Flags: needinfo?(cosmin.malutan)
Crashes in testPreferences_masterPassword/test1.js

I ran the restart test for 50 times and it didn't failed, so i't really lower occurrence than the last time. I will try to reproduce it when it will fail again in production.
Flags: needinfo?(cosmin.malutan)
Assignee: ttaubert → nobody
This remains our #2 topcrash on Mac OSX for Firefox 28. Any progress investigating this issue?
Flags: needinfo?(cosmin.malutan)
I haven't made any progress here, I will give more info when I will have any.
I will keep the flag so I don't miss this.
I think we need someone from QA here to get more information about this crash. Also a correlation of installed add-ons and plugins might be helpful. Robert, can you have a look at this?
Flags: needinfo?(kairo)
Keywords: qawanted
We're out of time on FF28 - we'll have to see what happens when this ships but at this point we do not have anything even speculative.
CC'ing Olli who has written some code in that area. He may have some insight or speculation what it could be.
(In reply to Henrik Skupin (:whimboo) from comment #21)
> I think we need someone from QA here to get more information about this
> crash. Also a correlation of installed add-ons and plugins might be helpful.
> Robert, can you have a look at this?

Nothing interesting in correlations and nothing else that sticks out. Getting a reproducible case would be interesting, but there's nothing else QA can do, this might need a developer to look into a dump or reproduce this in a debugger and poke around to find the issue.
Flags: needinfo?(kairo)
Kairo, with the release of 28, have you been able to get more information about this bug?
Flags: needinfo?(kairo)
Tagging 29 as unaffected and removing the tracking.
If it finally appears in 29, just let me know.
Flags: needinfo?(cosmin.malutan)
I'm resolving this bug WORKSFORME for now. I looked at Socorro and there are only 2 reports both of which are on Firefox 28. I don't think this is worth looking into anymore. Please reopen if this becomes a larger problem.
Closed: 7 years ago6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.