Closed Bug 595604 Opened 10 years ago Closed 10 years ago

Crash on peacekeeper benchmark [@ js_GetPropertyHelper(JSContext*, JSObject*, int, unsigned int, js::Value*) ] or [@ js::mjit::ic::GetProp(js::VMFrame&, unsigned long) ] or [@ WillDeadlock ]

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: scoobidiver, Assigned: dmandelin)

References

Details

(Keywords: crash, regression, Whiteboard: fixed-in-tracemonkey)

Crash Data

Attachments

(1 file)

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

This is a new crash signature.
According to all the comments, it happens when running peacekeeper benchmark.
The first comment was written about b6pre/20100909 build.
I can not reproduce.

Signature	js_GetPropertyHelper(JSContext*, JSObject*, int, unsigned int, js::Value*)
UUID	79462e1a-4f8d-48a3-84a9-823942100911
Time 	2010-09-11 10:09:14.459319
Uptime	9735
Last Crash	73212 seconds (20.3 hours) before submission
Install Age	9840 seconds (2.7 hours) since version was first installed.
Product	Firefox
Version	4.0b6pre
Build ID	20100911044632
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	AuthenticAMD family 16 model 5 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x5b184110
User Comments	Peacekeeper benchmark. Fading orange squares test
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0611

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	js_GetPropertyHelper 	js/src/jsobj.cpp:4779
1 	xul.dll 	js_GetProperty 	js/src/jsobj.cpp:4863
2 	xul.dll 	js::mjit::ic::GetProp 	js/src/methodjit/PolyIC.cpp:2067
These two crashes happens also when running Peacekeeper with method JIT. Once is different (hint of a dead lock), the other similar to the one reported buy on the GetProp:

http://crash-stats.mozilla.com/report/index/e641c148-d549-415f-b9dd-6499b2100913
http://crash-stats.mozilla.com/report/index/bp-824eb3e8-6e14-4ad6-a300-091212100913
Summary: Crash on peacekeeper benchmark [@ js_GetPropertyHelper(JSContext*, JSObject*, int, unsigned int, js::Value*) ] → Crash on peacekeeper benchmark [@ js_GetPropertyHelper(JSContext*, JSObject*, int, unsigned int, js::Value*) ] or [@ js::mjit::ic::GetProp(js::VMFrame&, unsigned long) ] or [@ WillDeadlock ]
blocking2.0: --- → ?
I get the ic::GetProp version. Apparently a bogus object (address looks like it might be ok, but contents are mostly 0xdadadada) is getting read in from the stack. I wonder if this could be a thread/GC fault.
We know the cause now. The call IC update() method calls the compiler, but without pushing a frame for the function being compiled. This is required so that if the compiler fails, we can throw an exception from the function we are trying to call. It also happens that the compiler, in the callprop_str case, calls js_GetClassPrototype with a NULL scope chain. This does the lookup using the current scope chain. But this is wrong if we haven't pushed a frame: we're using the scope chain of the caller instead of the callee.

The crash here could probably be quick-fixed by passing globalObj to js_GetClassPrototype in the compiler. But we want to fix it better by pushing the frame. This will take a little longer, because the update() function needs to be rearranged a bit for that to work. But hopefully I can still get it knocked off tomorrow.
Attached patch PatchSplinter Review
Assignee: general → dmandelin
Status: NEW → ASSIGNED
Attachment #475265 - Flags: review?(dvander)
Comment on attachment 475265 [details] [diff] [review]
Patch

I like the new UncachedCallResult, just one nit:

>+        // TODO check on this condition.

TODO
Attachment #475265 - Flags: review?(dvander) → review+
Also, we could avoid bloating CallICInfo by passing in regs.pc from before the call, but seems unimportant.
http://hg.mozilla.org/tracemonkey/rev/0618119a1f3d

Thanks for catching the TODO. We went over it verbally, which is probably why I forgot to delete the comment.
Whiteboard: fixed-in-tracemonkey
Hi All, new to this too. I started getting this crash too with pre7. Not sure if you all got this hammered out yet, but here's my log from today's build just in case. I got a different memory address and different thread than above though.

I was wondering initially if this was due the acceleration, but I turned everything off/disabled and still dropping out on me. Appears from this thread it isn't.


Signature	@cb1eddd2
UUID	16b8bd84-a106-45d7-9b39-8a7b02100915
Process Type	
Time 	2010-09-15 21:36:19.682194
Uptime	83
Last Crash	340 seconds (5.7 minutes) before submission
Install Age	731 seconds (12.2 minutes) since version was first installed.
Product	Firefox
Version	4.0b7pre
Build ID	20100915073756
Branch	2.0
OS	Windows NT
OS Version	6.0.6002 Service Pack 2
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 13
Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	ffffffffcb1eddd2
User Comments	Clean profile - everything set to off/disabled, still crashing
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0427
Processor Notes 	No module was identified as Flash
EMCheckCompatibility	True
Bugzilla - Report this Crash
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@cb1eddd2 	
1 	xul.dll 	JSObject::getProperty 	js/src/jsobj.h:1042
2 	xul.dll 	js::mjit::ic::GetProp 	js/src/methodjit/PolyIC.cpp:2077
Also, d452582b-1991-4670-8271-68bc72100915

That's first one for me.
http://hg.mozilla.org/mozilla-central/rev/0618119a1f3d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: 595975
Duplicate of this bug: 597313
blocking2.0: ? → betaN+
No longer blocks: 595975
Crash Signature: [@ js_GetPropertyHelper(JSContext*, JSObject*, int, unsigned int, js::Value*) ] [@ js::mjit::ic::GetProp(js::VMFrame&, unsigned long) ] [@ WillDeadlock ]
You need to log in before you can comment on or make changes to this bug.