Closed
Bug 736012
Opened 13 years ago
Closed 13 years ago
Assertion failure: enumerators == cx->enumerators, at jsinterp.cpp:453 or Crash [@ js_SuppressDeletedProperty]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
mozilla14
Tracking | Status | |
---|---|---|
firefox13 | + | fixed |
firefox14 | + | fixed |
firefox-esr10 | --- | unaffected |
People
(Reporter: decoder, Assigned: luke)
Details
(Keywords: assertion, crash, testcase, Whiteboard: [sg:critical][advisory-tracking+])
Crash Data
Attachments
(1 file, 1 obsolete file)
4.76 KB,
patch
|
bhackett1024
:
review+
akeybl
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
The following test asserts/crashes on mozilla-central revision dfcb11712ec2 (options -m -n):
var lfcode = new Array();
lfcode.push("\
function fatty() {\
try { fatty(); } catch (e) {\
for each (foo in [1]) {}\
}\
}\
fatty();\
");
lfcode.push("gc()");
lfcode.push("");
while (true) {
var file = lfcode.shift(); if (file == undefined) { break; }
evaluate(file);
}
Crash trace:
==63414== Invalid read of size 1
==63414== at 0x4848F0: js_SuppressDeletedProperty(JSContext*, JSObject*, long) (jsiter.cpp:1002)
==63414== by 0x424B31: js::array_shift(JSContext*, unsigned int, JS::Value*) (jsarray.cpp:2559)
==63414== by 0x483018: js::InvokeKernel(JSContext*, js::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:314)
==63414== by 0x47EB8D: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) (jsinterp.cpp:2710)
==63414== by 0x483AFD: js::Execute(JSContext*, JSScript*, JSObject&, JS::Value*) (jsinterp.cpp:668)
==63414== by 0x4187F6: JS_ExecuteScript (jsapi.cpp:5275)
==63414== by 0x408294: Process(JSContext*, JSObject*, char const*, bool) (js.cpp:478)
==63414== by 0x40AF03: Shell(JSContext*, js::cli::OptionParser*, char**) (js.cpp:4751)
==63414== by 0x40B5C5: main (js.cpp:5044)
==63414== Address 0x30 is not stack'd, malloc'd or (recently) free'd
Possibly related to bug 734987?
I'm marking this S-s because the bug requires "gc()" although the crash looks like a null-pointer crash. Please triage and remove S-s if appropriate :)
![]() |
Assignee | |
Comment 1•13 years ago
|
||
This is another pre-existing issue flushed out by bug 732744. In this case, an error while jaeger-shotting at a loop header pops the frame without jumping to 'error' first.
IIUC, this is on aurora. I'd like to let the fix bake a bit on m-c, though.
Whiteboard: js-triage-needed → js-triage-done
![]() |
Assignee | |
Comment 2•13 years ago
|
||
![]() |
Assignee | |
Comment 3•13 years ago
|
||
Comment on attachment 606310 [details] [diff] [review]
fix and test
Erm, nevermind, that's totally wrong.
Attachment #606310 -
Attachment is obsolete: true
Attachment #606310 -
Flags: review?(bhackett1024)
![]() |
Assignee | |
Comment 4•13 years ago
|
||
So, actually reading the comment this time, Jaeger_Throwing indicates that the current frame has finished. Thus it is wrong to 'goto error' in general for Jaeger_Throwing. The general case of exception-thrown-in-jit-code is handled corectly by FindExceptionHandler. It is only the special case of "failure to reserve stack space" in CheckStackAndEnterMethodJit that leaves us in this weird state. Unfortunately, I don't see a better fix than introducing yet another enum return. Let me know if you have any bright ideas Brian.
Attachment #606332 -
Flags: review?(bhackett1024)
Updated•13 years ago
|
Attachment #606332 -
Flags: review?(bhackett1024) → review+
![]() |
Assignee | |
Comment 5•13 years ago
|
||
![]() |
Assignee | |
Comment 6•13 years ago
|
||
Comment on attachment 606332 [details] [diff] [review]
fix
[Approval Request Comment]
Regression caused by (bug #): bug 732744
User impact if declined: crash
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): small patch, has some risk, but we still have a lot of time for this to bake.
Attachment #606332 -
Flags: approval-mozilla-aurora?
Comment 7•13 years ago
|
||
(In reply to Luke Wagner [:luke] from comment #6)
> Risk to taking this patch (and alternatives if risky): small patch, has some
> risk, but we still have a lot of time for this to bake.
1) Do we expect this crash to be more pronounced with our GA? Right now there's only a handful of crashes on 13
2) Do you expect that any possible regressions will be apparent over the 11 weeks before release?
Thanks!
![]() |
Assignee | |
Comment 8•13 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #7)
1) no
2) yes. 11 weeks of fuzzing should be plenty :)
Comment 9•13 years ago
|
||
Comment on attachment 606332 [details] [diff] [review]
fix
[Triage Comment]
Approved for Aurora 13 since we believe we'll find any regressions prior to release.
Attachment #606332 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Updated•13 years ago
|
![]() |
Assignee | |
Comment 11•13 years ago
|
||
Reporter | ||
Updated•13 years ago
|
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
status-firefox-esr10:
--- → unaffected
Comment 12•13 years ago
|
||
Was Firefox 12 unaffected by this?
Updated•13 years ago
|
Whiteboard: [sg:critical] → [sg:critical][advisory-tracking+]
Updated•13 years ago
|
Group: core-security
Reporter | ||
Comment 13•13 years ago
|
||
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/testBug736012.js.
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•