Closed
Bug 772770
Opened 12 years ago
Closed 12 years ago
"Assertion failure: cx->iterValue.isMagic(JS_NO_ITER_VALUE),"
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 677957
People
(Reporter: gkw, Assigned: jimb)
References
Details
(Keywords: assertion, regression, testcase, Whiteboard: [js:p1:fx17][fuzzblocker])
Attachments
(3 files, 1 obsolete file)
5.69 KB,
text/plain
|
Details | |
10.58 KB,
text/plain
|
Details | |
4.01 KB,
patch
|
Details | Diff | Splinter Review |
o2 = ({}).__proto__; o2.v = ""; with(Proxy.create((function() { return { has: function() {} } })())) { for each(d in 4); } asserts js debug shell on m-c changeset 53860f11100c without any CLI arguments at Assertion failure: cx->iterValue.isMagic(JS_NO_ITER_VALUE),
Reporter | ||
Comment 1•12 years ago
|
||
autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 98766:a5dacb3e58bd user: Jim Blandy date: Mon Jul 09 13:19:09 2012 -0700 summary: Bug 769754: Debugger handler functions should not corrupt the debuggee's JSContext::iterValue. r=jorendorff Also related to bug 677032 or bug 677957? (both simiar-looking / inverse assertions)
Blocks: 769754
Comment 2•12 years ago
|
||
I keep hitting this too with a lot of different stacks.
Whiteboard: js-triage-needed → js-triage-needed [fuzzblocker]
Comment 3•12 years ago
|
||
Thanks for using the fuzzblocker tag--that tells me to put a higher priority on it.
Whiteboard: js-triage-needed [fuzzblocker] → [js:p1][fuzzblocker]
Comment 4•12 years ago
|
||
We're seeing this on startup in Thunderbird now as well, now that bug 769754 has landed. Here's my stack.
Comment 5•12 years ago
|
||
Also, I'm experiencing this problem on Ubuntu Linux, so I'm broadening the affected platforms.
OS: Mac OS X → All
Comment 6•12 years ago
|
||
This is really starting to affect us Thunderbird developers, as it's making our trunk debug builds unusable... Any chance somebody on the JS team could take a look at this?
Unusable means that in some profiles (cause unknown so far) TB crashes on startup so no development/testing can be done.
Comment 8•12 years ago
|
||
We'll put it on the fix list for this cycle.
Whiteboard: [js:p1][fuzzblocker] → [js:p1:fx17][fuzzblocker]
Assignee | ||
Comment 9•12 years ago
|
||
I can reproduce this, and I've worked in this area recently.
Assignee: general → jimb
Assignee | ||
Comment 10•12 years ago
|
||
I added the failing assertion in bug 769754, so we could find errors of the sort addressed in that bug more quickly --- and here we have a new one. Proxies can cause arbitrary JS code to run while we've got a value saved in JSContext::iterValue. For example, this code will crash, even without the jsinterp.cpp assertion. o2 = ({}).__proto__; o2.v = ""; with(Proxy.create((function() { return { has: function() { for each(e in []); } }; })())) { for each(d in 4); }
Assignee | ||
Comment 11•12 years ago
|
||
I think this should fix this crash.
Assignee | ||
Comment 12•12 years ago
|
||
Try: https://tbpl.mozilla.org/?tree=Try&rev=7dca1dd58080
Assignee | ||
Comment 13•12 years ago
|
||
I omitted a test from the first version of this patch; this patch has both of them. Jason, it's looking like Try thinks the patch is okay. Should be pretty simple to review, and it's a high priority for the Thunderbird guys.
Attachment #645984 -
Attachment is obsolete: true
Attachment #646039 -
Flags: review?(jorendorff)
Assignee | ||
Comment 14•12 years ago
|
||
I've filed bug 777956 as a follow-up.
Comment 15•12 years ago
|
||
Just a heads up - sometime yesterday, we noticed this crash is no longer affecting Thunderbird. Debug builds can start-up just fine it seems. So, at least for Thunderbird, the urgency has lessened somewhat. Thanks for your work!
Comment 16•12 years ago
|
||
I'd like to try to land bug 677957 instead. Unbitrotting in that bug.
Comment 17•12 years ago
|
||
The patch in bug 677957 fixes the test cases in comment 0 and comment 10.
Comment 18•12 years ago
|
||
In the test cases here, the issue is that JS code is trying to run between MOREITER and ITERNEXT, because a property lookup occurs while binding the target variable 'd'. That is exactly what bug 677957 aims to fix, but it works by changing the bytecode so that MOREITER and ITERNEXT happen closer together in time. They are still separate instructions, and there's a JSOP_IFNE that happens in between. So my question for Jim is: do you think we can still get this error somehow using the Debugger? If so, can you construct the test case?
Assignee | ||
Comment 19•12 years ago
|
||
js/src/jit-test/tests/debug/Frame-onStep-iterators.js should still trigger the bug, even if MOREITER and ITERNEXT are closer together --- assuming the handler is really getting called on every bytecode.
Comment 20•12 years ago
|
||
note i was running into this assertion during topsite checks with a aurora debug build too Assertion failure: cx->iterValue.isMagic(JS_NO_ITER_VALUE), at /work/mozilla/builds/aurora/mozilla-aurora/js/src/jsinterp.cpp:317 http://www.blogchina.com: EXIT STATUS: CRASHED signal 11 SIGSEGV (417.188005 seconds)
Assignee | ||
Comment 21•12 years ago
|
||
Comment on attachment 646039 [details] [diff] [review] Preserve JSContext::iterValue while we call scripted proxy handlers. We're going to go with the patch in bug 677957 instead.
Attachment #646039 -
Flags: review?(jorendorff)
Assignee | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Comment 23•11 years ago
|
||
A testcase for this bug was already added in the original bug (bug 677957).
Flags: in-testsuite-
You need to log in
before you can comment on or make changes to this bug.
Description
•