606960 - crash [@ js::Interpret(JSContext*, JSStackFrame*, unsigned int, JSInterpMode) ]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

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

It is a new crash signature that first appeared in b8pre/20101020 build.
It is #61 top crasher in 4.0b8pre for the last 3 days.

Signature	js::Interpret(JSContext*, JSStackFrame*, unsigned int, JSInterpMode)
UUID	6dbbcc0d-61a0-4a9d-a12c-b96702101025
Time 	2010-10-25 02:46:54.279638
Uptime	29
Last Crash	35 seconds before submission
Install Age	54924 seconds (15.3 hours) since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101024042142
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	AuthenticAMD family 6 model 8 stepping 1
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x6756cc00
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0322

Frame 	Module 	Signature [Expand] 	Source
0 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:5270
1 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:637
2 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:740
3 	mozjs.dll 	js_fun_call 	js/src/jsfun.cpp:2248
4 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4695
5 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:637
6 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:740
7 	mozjs.dll 	js_fun_call 	js/src/jsfun.cpp:2248
8 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4695
9 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:637
10 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:740
11 	mozjs.dll 	js_fun_apply 	js/src/jsfun.cpp:2369
12 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4695
13 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:637
14 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:740
15 	mozjs.dll 	js_fun_apply 	js/src/jsfun.cpp:2369
16 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:4695
17 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:637
18 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:740
19 	mozjs.dll 	js::ExternalInvoke 	js/src/jsinterp.cpp:855
20 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:4960
21 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694
22 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:571
23 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
24 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
25 	xul.dll 	nsDOMEventListenerWrapper::HandleEvent 	content/events/src/nsDOMEventTargetHelper.cpp:65
26 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1112

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c9df0c5cbf8c&tochange=7aa9763e9d41

More reports at:
http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=js%3A%3AInterpret%28JSContext*%2C%20JSStackFrame*%2C%20unsigned%20int%2C%20JSInterpMode%29

Comment 1

[chris hofmann]

yeah, there was an unusual increase in volume in last week, but it seems to have dropped off.  the high volume build that is crashing seems to be from nov 23, and builds after that seem lower in volume.

         js::Interpret.JSContext.,.JSStackFrame.,.unsigned.int,.JSInterpMode.
date     total    breakdown by build
         crashes  count build, count build, ...

20101120 43  	33 4.0b72010110414, 
        		5 4.0b8pre2010111404, 	3 4.0b8pre2010111904, 
        		1 4.0b8pre2010112004, 	1 4.0b8pre2010111704, 
20101121 37 4.0b72010110414 	37 , 
20101122 40  	36 4.0b72010110414, 
        		4 4.0b8pre2010112104, 
20101123 30  	27 4.0b72010110414, 
        		3 4.0b8pre2010112205, 
20101124 51  	25 4.0b8pre2010112304, 
        		17 4.0b72010110414, 	4 4.0b8pre2010112004, 
        		4 4.0b8pre2010111604, 	1 4.0b8pre2010112205, 
20101125 142  	67 4.0b8pre2010112304, 
        		42 4.0b8pre2010112404, 	18 4.0b72010110414, 
        		6 4.0b8pre2010111904, 	4 4.0b8pre2010112205, 
        		3 4.0b8pre2010112004, 	2 4.0b8pre2010112503, 
20101126 71  	22 4.0b72010110414, 
        		12 4.0b8pre2010112104, 	9 4.0b8pre2010112404, 
        		9 4.0b8pre2010112304, 	7 4.0b8pre2010112205, 
        		4 4.0b8pre2010111811, 	4 4.0b8pre2010111004, 
        		3 4.0b8pre2010112503, 	1 4.0b8pre2010110504, 
20101127 206  	85 4.0b8pre2010112304, 
        		38 4.0b8pre2010112205, 	25 4.0b8pre2010111604, 
        		22 4.0b72010110414, 	13 4.0b8pre2010112104, 
        		9 4.0b8pre2010112004, 	5 4.0b8pre2010111811, 
        		4 4.0b8pre2010112503, 	2 4.0b8pre2010112703, 
        		2 4.0b8pre2010112404, 	1 4.0b8pre2010112611, 
20101128 179  	54 4.0b8pre2010112304, 
        		49 4.0b72010110414, 	33 4.0b8pre2010112104, 
        		18 4.0b8pre2010112205, 	6 4.0b8pre2010111704, 
        		5 4.0b8pre2010112004, 	5 4.0b8pre2010111904, 
        		4 4.0b8pre2010111604, 	2 4.0b8pre2010112404, 
        		2 4.0b8pre2010111504, 	1 4.0b8pre2010112503,

Comment 2

[Scoobidiver (away)]

It is #19 top crasher in 4.0b10. Here are some module correlations:
91% (42/46) vs.   0% (46/18801) amvo0.dll (malware)
74% (34/46) vs.   0% (74/18801) ggwhook.dll (Polish instant messenger)

Comment 3

[Carlos Roberto]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre

Always crashing here:

http://www.edgevertise.com/

Cannot reproduce with 3.5.18pre.

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

(In reply to comment #3)
> Always crashing here:
> http://www.edgevertise.com/

Confirmed: bp-4860b4ff-597d-45bd-a98a-77e9f2110222

If I block the Script "<script type="text/javascript" src="http://edgenet.edgevertise.com/edgevertise/epanel/shared/php/js.php?id=1"></script>", what seems to be responsible of the Sidebar Thingy, using a suitable Adblocker the Crash does not happen.

Maybe someone can extract a Testcase/Crashtest out of it?

Comment 5

[chris hofmann]

pretty consistently 150-200 crashes per day for the last several weeks.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: fix

The problem here is that a script is getting destroyed in EvaluateUCScriptForPrincipalsCommon. Its prop cache entries are not purged because it's an eval frame. Then later the same script memory is reused, and we crash because the prop cache entries are no longer valid.

On IRC we talked about passing a flag here to say whether was already purged by the GC. However, I think that the existing test (!cx->runtime->gcRunning) should be sufficient. I still don't totally understand all this, but this seems like the safest option. And I'm pretty sure that we won't ever purge anything twice.

Comment 7

[Brendan Eich [:brendan]]

Comment on attachment 514378 [details] [diff] [review]
fix

Thanks, much better than a flag parm. Could you please add an assertion that the gc is not running to js::PropertyCache::purgeForScript?

/be

Comment 8

[Brendan Eich [:brendan]]

Safe, simple fix for a #61 topcrash bug. I think we should take it.

/be

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Switching from blocking to approval flag - we're not blocking (as in, would stop ship if the issue got re-opened) on topcrashes that aren't in the top 10 or 20.

Comment 10

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

http://hg.mozilla.org/tracemonkey/rev/cf3c73cbd883

Comment 11

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/cf3c73cbd883

Comment 12

[Scoobidiver (away)]

It still crashes in 4.0b13pre/20110226. See:
bp-b055a078-7df0-4bc6-a3fe-c76012110226
bp-9faec8c9-7416-456a-82f5-108ea2110226

Comment 13

[Carlos Roberto]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre

It is fixed, cannot reproduce.

Comment 14

[Scoobidiver (away)]

> It is fixed, cannot reproduce.
If you use STR in comment 4, but this bug is not associated to particular STR.

Comment 15

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Sorry, I should have looked at the crash reports before marking this fixed. Looking at them now, there seem to be a lot of different bugs causing us to crash in Interpret. We should probably treat this more as a meta-bug, sort of like the EnterMethodJIT bug.

Comment 16

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to comment #12)
> It still crashes in 4.0b13pre/20110226.

This bug has a patch that fixed a particular Interpret crash; it should stay closed and a new bug opened for new Interpret crashes.

Comment 17

[Scoobidiver (away)]

Per comment 16, I closed it again as fixed.