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

Status: RESOLVED WORKSFORME

Description

[Panos Astithas [:past] (please ni?)]

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: https://gist.github.com/3893467

I'm on fx-team tip and at that particular moment I had an experimental add-on running: https://github.com/scrapmac/Graphical-Timeline-of-Events

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

[Jim Blandy :jimb]

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

https://bugzilla.mozilla.org/show_bug.cgi?id=777596

Comment 2

[Jim Blandy :jimb]

Let's get that gist into the bug...

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

Comment 3

[Jim Blandy :jimb]

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

[Jim Blandy :jimb]

I can reproduce this crash fairly easily. Taking up 777596 again, and suggesting we reconsider its priority.

Comment 5

[Jim Blandy :jimb]

(It is indeed caused by the slow script dialog.)

Comment 6

[Panos Astithas [:past] (please ni?)]

(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.

Comment 7

[Jim Blandy :jimb]

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.