Closed
Bug 595604
Opened 14 years ago
Closed 14 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)
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)
15.67 KB,
patch
|
dvander
:
review+
|
Details | Diff | Splinter Review |
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
Comment 1•14 years ago
|
||
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
Reporter | ||
Updated•14 years ago
|
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 ]
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Assignee | ||
Comment 2•14 years ago
|
||
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.
Assignee | ||
Comment 3•14 years ago
|
||
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.
Assignee | ||
Comment 4•14 years ago
|
||
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.
Assignee | ||
Comment 7•14 years ago
|
||
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
Comment 8•14 years ago
|
||
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
Comment 9•14 years ago
|
||
Also, d452582b-1991-4670-8271-68bc72100915 That's first one for me.
Comment 10•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/0618119a1f3d
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
blocking2.0: ? → betaN+
Updated•13 years ago
|
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.
Description
•