Closed Bug 962846 Opened 12 years ago Closed 10 years ago

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

Categories

(Core :: DOM: Workers, defect)

Product:
Core
Component:
DOM: Workers
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox26 --- unaffected
firefox27 --- unaffected
firefox28 + wontfix
firefox29 - unaffected
firefox30 --- unaffected

People

(Reporter: u279076, Unassigned)

References

Details

(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: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozalloc_abort%28char+const%2A%29+%7C+Abort+%7C+NS_DebugBreak+%7C+GCGraphBuilder%3A%3ADescribeRefCountedNode%28unsigned+int%2C+char+const%2A%29 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 (:kairo@mozilla.com) 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?(anthony.s.hughes)
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?(anthony.s.hughes)
Keywords: verifyme
QA Contact: anthony.s.hughes
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.
Keywords: topcrash-mac, verifyme
0 reports for Firefox 30.0a1: https://crash-stats.mozilla.com/query/?product=Firefox&version=Firefox%3A30.0a1&range_value=1&range_unit=weeks&date=02%2F07%2F2014+22%3A00%3A00&query_search=signature&query_type=contains&query=mozalloc_abort%28char+const*%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: https://crash-stats.mozilla.com/query/?product=Firefox&version=Firefox%3A29.0a2&range_value=1&range_unit=weeks&date=02%2F07%2F2014+22%3A00%3A00&query_search=signature&query_type=contains&query=mozalloc_abort%28char+const*%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: https://crash-stats.mozilla.com/query/?product=Firefox&version=Firefox%3A28.0b&range_value=1&range_unit=weeks&date=02%2F07%2F2014+22%3A00%3A00&query_search=signature&query_type=contains&query=mozalloc_abort%28char+const*%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.
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox28: affected → verified
status-firefox29: affected → verified
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/testrun.py", 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/testrun.py", line 573, in run_tests >15:03:32 TestRun.run_tests(self) Crash report: https://crash-stats.mozilla.com/report/index/e2367773-fadb-4978-b4c7-c84c82140219 Testrun report: http://mozmill-release.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f414a173
status-firefox28: verified → affected
status-firefox30: --- → verified
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.
Status: REOPENED → ASSIGNED
status-firefox29: verified → affected
status-firefox30: verified → unaffected
Flags: needinfo?(kairo)
Flags: needinfo?(anthony.s.hughes)
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?(anthony.s.hughes)
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 http://mozmill-release.blargon7.com/#/functional/report/6062fdddb60e88657bc78ec1f414a173 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
Status: ASSIGNED → NEW
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.
status-firefox28: affected → wontfix
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? thanks
Flags: needinfo?(kairo)
Tagging 29 as unaffected and removing the tracking. If it finally appears in 29, just let me know.
status-firefox29: affected → unaffected
tracking-firefox29: + → -
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.
Status: NEW → RESOLVED
Closed: 12 years ago → 10 years ago
Keywords: qawanted, topcrash-mac
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.