866397 - crash in js::ion::DoTypeMonitorFallback

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

It's bug 864125 without js::types::TypeScript::SetArgument (fixed in bug 860145) in the stack trace and is #4 in today's build. So the regression range is in bug 864125 comment 0.

Signature 	js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&) More Reports Search
UUID	2259e9bb-0291-49a6-95e3-415f22130426
Date Processed	2013-04-26 18:11:45
Uptime	14
Last Crash	32 seconds before submission
Install Age	10.0 minutes since version was first installed.
Install Time	2013-04-26 18:01:35
Product	Firefox
Version	23.0a1
Build ID	20130426030834
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 42 stepping 7
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x4
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x1040, AdapterSubsysID: 00000000, AdapterDriverVersion: 9.18.13.1407
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
Processor Notes 	sp-processor08.phx1.mozilla.com_32693:2012
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x1040
Total Virtual Memory	4294836224
Available Virtual Memory	3727540224
System Memory Use Percentage	57
Available Page File	6354821120
Available Physical Memory	2717958144

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	js::types::TypeMonitorResult 	js/src/jsinfer.cpp:5859
1 	mozjs.dll 	js::ion::DoTypeMonitorFallback 	js/src/ion/BaselineIC.cpp:1160
2 		@0x2fd71c 	

More reports at:
https://crash-stats.mozilla.com/report/list?version=Firefox:23.0a1&signature=js%3A%3Atypes%3A%3ATypeMonitorResult%28JSContext*%2C+JSScript*%2C+unsigned+char*%2C+JS%3A%3AValue+const%26%29
https://crash-stats.mozilla.com/report/list?version=Firefox:23.0a1&signature=js%3A%3Aion%3A%3AICTypeMonitor_Fallback%3A%3AaddMonitorStubForValue%28JSContext*%2C+JS%3A%3AHandle%3CJSScript*%3E%2C+JS%3A%3AHandle%3CJS%3A%3AValue%3E%29

Comment 1

[Nicolas B. Pierron [:nbp]]

The address 0xe reported in this crash is likely coming from types->hasType(…), which inline unknown(), which check the flags_ field against the mask 0x00010000.  This means that "types" is likely NULL.

Types is returned by “script->analysis()->bytecodeTypes(pc);” inside js::types::TypeMonitorResult.  This function is called from the code generated for ICTypeMonitor_Fallback.

My guess is that we just got a GC while we were executing the baseline code, and then jump into the DoTypeMonitorFallback IC, which tries to access the bytecode types which have been removed because of the GC.

djvj & jandem, How easy would it be to make a test case for that? something like:

f() {
  gc()
  … do type monitor fallback …
}

Comment 2

[Cameron McCormack (:heycam)]

I can reasonably reliably reproduce this by visiting https://www.ubank.com.au/ubank/web/products/home-loan.

Comment 3

[Scoobidiver (away)]

Since 23.0a1/20130428, there have been only one crash: bp-73b80c0e-13da-445b-b952-776b82130429.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.