597834 - crash [@ @0x0 | DoDeferredRelease<nsISupports*> ]

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[Scoobidiver (away)]

Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100918 Firefox/4.0b7pre

This is a new crash signature that was introduced by b6pre/20100912 build.
It has a low daily rate : 1-5 crashes/day
It is #26 top crasher for b7pre/20100918 build.

Signature	@0x0 | DoDeferredRelease<nsISupports*>
UUID	b8185e4f-a4fc-4015-85a5-3ad532100918
Time 	2010-09-18 08:37:44.168843
Uptime	5149
Last Crash	510770 seconds (5.9 days) before submission
Install Age	8282 seconds (2.3 hours) since version was first installed.
Product	Firefox
Version	4.0b7pre
Build ID	20100918041706
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	AuthenticAMD family 15 model 12 stepping 0
Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	0x0
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0422

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@0x0 	
1 	xul.dll 	DoDeferredRelease<nsISupports*> 	js/src/xpconnect/src/xpcjsruntime.cpp:473
2 	xul.dll 	XPCJSRuntime::GCCallback 	js/src/xpconnect/src/xpcjsruntime.cpp:744
3 	xul.dll 	DOMGCCallback 	dom/base/nsJSEnvironment.cpp:3717
4 	xul.dll 	nsCategoryCache<nsIContentSniffer>::~nsCategoryCache<nsIContentSniffer> 	obj-firefox/dist/include/nsCategoryCache.h:94
5 	xul.dll 	XPCJSContextStack::Peek 	js/src/xpconnect/src/xpcthreadcontext.cpp:82
6 	nspr4.dll 	PR_Unlock 	nsprpub/pr/src/threads/combined/prulock.c:348
7 	xul.dll 	nsTHashtable<nsBaseHashtableET<nsCStringHashKey,unsigned int> >::Init 	obj-firefox/dist/include/nsTHashtable.h:348
8 	xul.dll 	JS_GC 	js/src/jsapi.cpp:2472
9 	xul.dll 	nsXPConnect::Collect 	js/src/xpconnect/src/nsXPConnect.cpp:397

Comment 1

[Sheila Mooney]

Scoobidiver, I still see this but not as a top crash. Do we still think it's a blocker candidate?

Comment 2

[Scoobidiver (away)]

Its ranking as a top crasher in 4.0b8pre is above 300. So I think a blocking status for Gecko 2.0 is no longer necessary.

Comment 3

[timeless]

blake: can we just take the obvious patch of NS_IF_RELEASE here? it's wrong, but i don't see a reason for our users to suffer while we sleep on it.

Comment 4

[timeless]

Attachment: spackle

Comment 5

[Benjamin Smedberg]

Can we maybe add an assertion here, so that if we do end up finding this in a debug build we'll notice and diagnose it?

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 486306 [details] [diff] [review]
spackle

I don't believe it's possible for this to help.

The crash here is in DoDeferredRelease<nsISupports *> which means that the array we're iterating is mNativesToBeReleasedArray. The only place that we add to that array is in XPCJSRuntime::DeferredRelease. Looking through all of the callers, we are protected by a null check in every case, so it should be impossible for a null value to ever end up in the array. I think, instead, what's happening here is that wrapper has already been free'd, and we're crashing trying to get the function pointer for 'Release()'.

Comment 7

[Robert Kaiser]

Can still be seen in crash stats, and bug 633668 might be related.

Comment 8

[Scoobidiver (away)]

There have been no crashes since 17.0.