"Assertion failure: cx->iterValue.isMagic(JS_NO_ITER_VALUE),"

RESOLVED DUPLICATE of bug 677957

Status

()

Core
JavaScript Engine
--
critical
RESOLVED DUPLICATE of bug 677957
6 years ago
5 years ago

People

(Reporter: gkw, Assigned: jimb)

Tracking

(Blocks: 3 bugs, {assertion, regression, testcase})

Trunk
x86_64
All
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:p1:fx17][fuzzblocker])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Created attachment 640974 [details]
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),
(Reporter)

Comment 1

6 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
I keep hitting this too with a lot of different stacks.
Blocks: 676763
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]
Created attachment 642719 [details]
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?

Comment 7

6 years ago
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]
(Assignee)

Comment 9

6 years ago
I can reproduce this, and I've worked in this area recently.
Assignee: general → jimb
(Assignee)

Comment 10

6 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

6 years ago
Created attachment 645984 [details] [diff] [review]
Preserve JSContext::iterValue while we call scripted proxy handlers.

I think this should fix this crash.
(Assignee)

Comment 13

6 years ago
Created attachment 646039 [details] [diff] [review]
Preserve JSContext::iterValue while we call scripted proxy handlers.

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

6 years ago
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?
(Assignee)

Comment 19

6 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.
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)
Blocks: 532972
(Assignee)

Comment 21

6 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

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 677957
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.