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)

x86_64
All
defect
Not set
critical

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)

Attached file stack
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),
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
I keep hitting this too with a lot of different stacks.
Whiteboard: js-triage-needed → js-triage-needed [fuzzblocker]
Thanks for using the fuzzblocker tag--that tells me to put a higher priority on it.
Whiteboard: js-triage-needed [fuzzblocker] → [js:p1][fuzzblocker]
Attached file Thunderbird stack
We're seeing this on startup in Thunderbird now as well, now that bug 769754 has landed.

Here's my stack.
Also, I'm experiencing this problem on Ubuntu Linux, so I'm broadening the affected platforms.
OS: Mac OS X → All
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.
We'll put it on the fix list for this cycle.
Whiteboard: [js:p1][fuzzblocker] → [js:p1:fx17][fuzzblocker]
I can reproduce this, and I've worked in this area recently.
Assignee: general → jimb
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);
}
I think this should fix this crash.
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)
I've filed bug 777956 as a follow-up.
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!
I'd like to try to land bug 677957 instead. Unbitrotting in that bug.
The patch in bug 677957 fixes the test cases in comment 0 and comment 10.
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?
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.
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)
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)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
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.

Attachment

General

Created:
Updated:
Size: