606536 - Firefox/4.0b8pre startup crash in [@ js_GetProtoIfDenseArray ]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Marcia Knous [:marcia]]

Seen while reviewing crash stats. http://tinyurl.com/32ky3fd links to the crashes which happen with 1.9.2 and 1.9.1 as well. While the trunk crashes are startup crashes, the other crashes seem to have more uptime so might provide more of a chance of reproducing the issue.

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	js_GetProtoIfDenseArray 	js/src/jsarray.h:131
1 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4178
2 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:638
3 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:747
4 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:871
5 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:4961
6 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694
7 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:571
8 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
9 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
10 	xul.dll 	nsComponentManagerImpl::CreateInstanceByContractID 	xpcom/components/nsComponentManager.cpp:1303
11 	xul.dll 	nsComponentManagerImpl::GetServiceByContractID 	xpcom/components/nsComponentManager.cpp:1664
12 	xul.dll 	nsCOMPtr_base::assign_from_gs_contractid 	obj-firefox/xpcom/build/nsCOMPtr.cpp:132
13 	xul.dll 	NS_CreateServicesFromCategory 	xpcom/components/nsCategoryManager.cpp:788
14 	xul.dll 	nsXREDirProvider::DoStartup 	toolkit/xre/nsXREDirProvider.cpp:754
15 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3546
16 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:129
17 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
18 	kernel32.dll 	BaseThreadInitThunk 	
19 	ntdll.dll 	__RtlUserThreadStart 	
20 	ntdll.dll 	_RtlUserThreadStart

Comment 1

[chris hofmann]

here are resent volume stats

might have seen the first instance of this on the trunk on oct 17 and oct 20 in builds from oct 10, but maybe thats the lower volume risidual crash.

the higher volume trunk problem might have started somewhere between 4.0b8pre2010101604 and 2010101804

20101015 7  3 3.6.102010091412, 
	        1 4.0b62010091408, 1 3.6.82010072215, 
	        1 3.6.72010071313, 1 3.6.32010040108, 
20101016 6  4 3.6.102010091412, 
	        1 3.6.82010072215, 1 3.5.132010091413, 
20101017 7  1 4.0b8pre2010101004, 
	        1 4.0b62010091408, 1 3.6.82010072215, 
	        1 3.6.112010101211, 1 3.6.102010091412, 
	        1 3.62010011514, 1 3.5.132010091413, 
20101018 5  4 3.6.102010091412, 
	        1 4.0b22010072019, 
20101019 10  7 3.6.102010091412, 
	        1 4.0b62010091408, 1 3.6.82010072215, 
	        1 3.6.62010062523, 
20101020 6  2 3.6.102010091412, 
	        1 4.0b8pre2010101904, 1 4.0b52010083108, 
	        1 3.6.32010040108, 1 3.6.112010101211, 
20101021 40  11 4.0b8pre2010101904, 
	        9 4.0b8pre2010101804, 7 4.0b8pre2010101704, 
	        5 4.0b8pre2010102004, 2 4.0b8pre2010101604, 
	        2 4.0b8pre2010101504, 2 3.6.102010091412, 
	        1 4.0b62010091408, 1 3.6.112010101211,

Comment 2

[chris hofmann]

moved to the #1 topcrash on trunk on oct 22 with 173 crashes.  need to understand this better before b7 or b8.   stats from yesterday don't show any crashes on trunk beyond 2010 10 20 so maybe the fix is in.

20101022 173  98 4.0b8pre2010101704, 
	        22 4.0b8pre2010101604, 19 4.0b8pre2010101804, 
	        17 4.0b8pre2010101904, 10 4.0b8pre2010102004, 
	        5 3.6.112010101211, 1 4.0b7pre2010100204, 
	        1 3.5.142010100117, 

Could this jsArray change that happened inside the the possible regression window be related?

c45685276ce5
2010-10-13 11:49 -0700	Brian Hackett - Flexible length JSObject, bug 584917. r=brendan,igor

Comment 3

[Brian Hackett [Laid off!]]

Looks like js_GetProtoIfDenseArray is getting passed a NULL pointer by CALLPROP in Interpret, don't think this is 584917.

Comment 4

[Brian Hackett [Laid off!]]

Is this fixed?  There haven't been any crashes with builds after 10/20.

Comment 5

[Damon Sicore (:damons)]

Do we really need to hold b7 for this?  We've gotta get it out the door!  I know there will be stability issues in b7, and we've hundreds of changes going into the beta. 

Just want to be super critical when blocking b7.  If we can get by without it, we should ship the beta and fix issues in a followup release.

Comment 6

[Robert Sayre]

(In reply to comment #4)
> Is this fixed?  There haven't been any crashes with builds after 10/20.

I misread choffman's summary in comment 2. I think we should mark this WFM if the crash is gone. If it is still the number 1 topcrash, it should block b7.

Comment 7

[chris hofmann]

It looks like this might have been a spike volume regression on the trunk builds between around oct 16-20.  I agree WFM is probably correct.