Closed Bug 482849 Opened 15 years ago Closed 11 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: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.