Closed Bug 482849 Opened 17 years ago Closed 13 years ago

Crash @ canonicalize

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
1.9.1 Branch
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 815141

People

(Reporter: tchung, Unassigned)

References

Details

(Keywords: crash, qawanted, Whiteboard: [needs a cycle collector hacker to evaluate the stack][TBtopcrash],str-wanted, [mobile-crash])

Crash Data

I hit this crash while doing a nightly update on 191nightly to Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090311 Shiretoko/3.1b4pre Ubiquity/0.1.5 Crash stack: http://crash-stats.mozilla.com/report/index/01b1ad52-bf3b-4f0c-8d35-30b6a2090311 Frame Module Signature [Expand] Source 0 XUL canonicalize xpcom/base/nsCycleCollector.cpp:1108 1 XUL GCGraphBuilder::NoteXPCOMChild xpcom/base/nsCycleCollector.cpp:1394 2 XUL nsGenericElement::cycleCollection::Traverse content/base/src/nsGenericElement.cpp:4058 3 XUL nsHTMLTableRowElement::cycleCollection::Traverse content/html/content/src/nsHTMLTableRowElement.cpp:101 4 XUL GCGraphBuilder::Traverse xpcom/base/nsCycleCollector.cpp:1319 5 XUL nsCycleCollector::MarkRoots xpcom/base/nsCycleCollector.cpp:1519 6 XUL nsCycleCollector::BeginCollection xpcom/base/nsCycleCollector.cpp:2374 7 XUL nsCycleCollector_beginCollection xpcom/base/nsCycleCollector.cpp:2916 8 XUL XPCCycleCollectGCCallback js/src/xpconnect/src/nsXPConnect.cpp:391 9 libmozjs.dylib js_GC js/src/jsgc.cpp:3534 10 libmozjs.dylib JS_GC js/src/jsapi.cpp:2499 11 XUL nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:478 12 XUL nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:2256 13 XUL nsCycleCollector::Shutdown xpcom/base/nsCycleCollector.cpp:2477 14 XUL nsCycleCollector_shutdown xpcom/base/nsCycleCollector.cpp:2938 15 XUL NS_ShutdownXPCOM_P xpcom/build/nsXPComInit.cpp:816 16 XUL ScopedXPCOMStartup::RegisterProfileService toolkit/xre/nsAppRunner.cpp:951 17 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3320 18 firefox-bin main browser/app/nsBrowserApp.cpp:156 19 firefox-bin firefox-bin@0x1541 20 firefox-bin firefox-bin@0x1468 21 @0x0
I hit this while simply scrolling a page today using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090430 Minefield/3.6a1pre. Will try to find the page that I was on when the crash occurred.
peterv, can you make sense of the crash stack? If not, we might as well mark this bug as incomplete.
Severity: normal → critical
Whiteboard: [needs a cycle collector hacker to evaluate the stack]
top 10 crash for thunderbird 3.0b4. interestingly, 90% of FF crashes are Mac. But not so for thunderbird. one FF comment bp-e03534f4-7be3-4c30-ac4a-018eb2090914 "keeps crashing when I try to set up Drupal through cpanel at Justohst. Happened 2x - once using uplader in cpanel - second time setting up ftp" have we found a cycle collector hacker to evaluate the stack?
Keywords: crash
need to assess whether tb3needs. note whiteboard
Keywords: qawanted
Just looking at the stacks there's not a lot to go on. Can't figure it out from the few I looked at. Note that some of these stacks end in the same function, but look like different bugs (coming from cycle collection code for different classes).
Peter: any chance looking through more of them would make a pattern become clear? Wayne: how many crashes do we have?
147 in 4 weeks = 5 crashes per day. My concern is entirely about thunderbird because: * we are going to a new release with much updating of extensions * a bad update experience will be ... bad * this is a core bug it may be hard to get a fix for RC1 (or even post release), even if it's deemed important * canonicalize's crash ranking has climbed significantly with every beta Is this is only extension updates, or is application update also clearly at risk? (comment 0 suggests the later) >look like different bugs (coming from cycle collection code for different classes) Peter: Would help if socorro presented these crashes with top 2 frames? canonicalize | <something> Also, what is likelihood some crashes may exist with a top of stack other than canonicalize? crashes with comments http://crash-stats.mozilla.com/report/index/6cc7e808-7cf9-4a5f-a274-7a6702090823 http://crash-stats.mozilla.com/report/index/5aaf0601-e514-4b72-a7fd-9b59f2090330 http://crash-stats.mozilla.com/report/index/dad01bc2-4b8f-4d92-8be8-a02c32090531 http://crash-stats.mozilla.com/report/index/36132f07-3f65-4b57-8b8f-6ed542090630 http://crash-stats.mozilla.com/report/index/d977c318-3813-4539-9608-49e252090713
OS: Mac OS X → All
Whiteboard: [needs a cycle collector hacker to evaluate the stack] → [needs a cycle collector hacker to evaluate the stack][TBtopcrash]
I crashed on that while checking emails after waiking up from sleep.
#43 crash for v3.1. #34 for v3.0.5 I crashed while typing in compose. perhaps because of being over quota? not 100% sure why bp-e4e87944-63ab-4810-84dd-b6bdc2100718 0 xpcom_core.dll canonicalize xpcom/base/nsCycleCollector.cpp:1176 1 xpcom_core.dll GCGraphBuilder::NoteXPCOMChild xpcom/base/nsCycleCollector.cpp:1460 2 thunderbird.exe nsEventListenerManager::cycleCollection::Traverse content/events/src/nsEventListenerManager.cpp:333 3 xpcom_core.dll GCGraphBuilder::Traverse xpcom/base/nsCycleCollector.cpp:1389 4 xpcom_core.dll nsCycleCollector::MarkRoots xpcom/base/nsCycleCollector.cpp:1611 5 xpcom_core.dll nsCycleCollector::BeginCollection xpcom/base/nsCycleCollector.cpp:2554 6 thunderbird.exe XPCCycleCollectGCCallback js/src/xpconnect/src/nsXPConnect.cpp:391 7 js3250.dll js_GC js/src/jsgc.cpp:3537 8 js3250.dll JS_GC js/src/jsapi.cpp:2439 9 thunderbird.exe nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:478 10 xpcom_core.dll nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:2434 11 xpcom_core.dll nsCycleCollector_collect xpcom/base/nsCycleCollector.cpp:3129 12 thunderbird.exe nsJSContext::CC dom/base/nsJSEnvironment.cpp:3621 13 thunderbird.exe nsJSContext::IntervalCC dom/base/nsJSEnvironment.cpp:3709 14 thunderbird.exe nsUserActivityObserver::Observe dom/base/nsJSEnvironment.cpp:268 15 xpcom_core.dll nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:130 FF trunk (4.0) crashes bp-539c6b04-0f95-492a-b4cd-d56692100712 https://input.mozilla.com/happy - i was trying to see what the inspect button does bp-c301c45b-5f6e-4507-bcc3-f97fc2100706 bp-e031c1d6-d1c4-4c8e-881d-24c132100712 FF 3.6 crashes with urls bp-5b6e09a2-25a7-474d-9415-7bc6a2100718 trying to download firefox on my mac bp-5b20cc6e-945c-4c9c-932c-c297c2100718 bp-8bae1320-ef6c-4775-b2e7-41ff22100716 bp-2395a22f-4eae-41de-a187-75ca52100717 bp-ddb63ba9-3c3a-4baa-9401-13a622100717
(In reply to comment #7) > Peter: any chance looking through more of them would make a pattern become > clear? No idea. The pattern is just that some objects hold a strong reference to another object but that other object seems to have gone away, and the strong reference looks stale. (In reply to comment #8) > Peter: Would help if socorro presented these crashes with top 2 frames? > canonicalize | <something> You could get socorro to split them up, but what would it show? Some of these might have the same cause, others might not. Unless you're sure they're definitely all having the same cause, or definitely not, having hte report one way or the other doesn't make a difference in understanding this imo. > Also, what is likelihood some crashes may exist > with a top of stack other than canonicalize? If these are stale pointers then it might crash anywhere we access the pointer.
xref Bug 622277 - crash [@ canonicalize] (which is topcrash for thunderbird on trunk - which may or may not mean much)
Crash Signature: [@ canonicalize ]
Similar crash happened on birch branch: https://crash-stats.mozilla.com/report/index/f8bb2d2a-26bd-4037-9e55-53e802111107
Whiteboard: [needs a cycle collector hacker to evaluate the stack][TBtopcrash] → [needs a cycle collector hacker to evaluate the stack][TBtopcrash],[native-crash]
Whiteboard: [needs a cycle collector hacker to evaluate the stack][TBtopcrash],[native-crash] → [needs a cycle collector hacker to evaluate the stack][TBtopcrash],[native-crash],str-wanted
Whiteboard: [needs a cycle collector hacker to evaluate the stack][TBtopcrash],[native-crash],str-wanted → [needs a cycle collector hacker to evaluate the stack][TBtopcrash],[native-crash:P3],str-wanted
Whiteboard: [needs a cycle collector hacker to evaluate the stack][TBtopcrash],[native-crash:P3],str-wanted → [needs a cycle collector hacker to evaluate the stack][TBtopcrash],str-wanted, [mobile-crash]
It happens on all platforms.
Hardware: x86 → All
Summary: Crash [@ canonicalize ] while doing a nightly update → Crash @ canonicalize
I saw this crash in Thunderbird 13 running on Linux OpenSuSE 11.4. bp-e9016eb7-3b12-4f4e-b136-e4cc52120608
per bug 815141 comment 6, in version 17 the crash changes to bug 815141
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.