Assertion failure: cx->iterValue.isMagic(JS_NO_ITER_VALUE), at js/src/jsinterp.cpp:340




6 years ago
10 months ago


(Reporter: past, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)

Created attachment 671477 [details]
Crash log

I only got this once and I haven't been able to reproduce it yet, but it happened while trying to run the scratchpad in this gist:

I'm on fx-team tip and at that particular moment I had an experimental add-on running:

Specifically the code in branch RDP that uses the remote debugging protocol, although the rest of the browser was idle for quite a while (besides the scratchpad) so this add-on shouldn't matter.

Comment 1

6 years ago
For an explanation of what this assertion means is going on, see the first comment of:

Comment 2

6 years ago
Let's get that gist into the bug...

var dbg = new Debugger();
for (var g of dbg.findAllGlobals())
  try {
  } catch (e) {
    dump("ignoring the debugger's compartment\n");
for (var s of dbg.findScripts())

Comment 3

6 years ago
Had the loop been running for a long time when you got the crash?

From the stack trace, it seems like you asked the sandbox to evaluate something (xpc_EvalInSandbox, frame 17), and then execution was interrupted --- by a timeout, it would appear --- and then we began running JavaScript to bring up the slow script dialog. As explained in bug 777596, if we begin running new JS between MOREITER and ITERNEXT bytecodes, this assertion triggers (because the new JS is about to screw up the interrupted JS's iteration).

If that's the case, then this has nothing to do with the debugger; it's just another manifestation of bug 777596. We can patch this as we did for bug 769754, but that's yet another band-aid; the fix described in 777596 is the better thing.

Comment 4

6 years ago
I can reproduce this crash fairly easily. Taking up 777596 again, and suggesting we reconsider its priority.
Depends on: 777596

Comment 5

6 years ago
(It is indeed caused by the slow script dialog.)
(In reply to Jim Blandy :jimb from comment #3)
> Had the loop been running for a long time when you got the crash?

I don't think so, but I could be wrong.


6 years ago
Blocks: 806820


6 years ago
Depends on: 831585
Assignee: general → nobody

Comment 7

10 months ago
Looking at the code now, the MOREITER and ITERNEXT bytecodes don't work the way they used to. In particular, there is no JSContext::iterValue field any more, and code seems to use a value on the stack; with this approach, the assertion failing in comment 0 doesn't need to exist, since there's no shared variable to protect.

If we don't have any evidence that this problem is still around, we should close this bug.


10 months ago
Last Resolved: 10 months ago
Resolution: --- → WORKSFORME


10 months ago
Duplicate of this bug: 815241
You need to log in before you can comment on or make changes to this bug.