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

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
RESOLVED WORKSFORME
6 years ago
26 days ago

People

(Reporter: past, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

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

6 years ago
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

6 years ago
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

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

Comment 6

6 years ago
(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.

Updated

5 years ago
Blocks: 806820

Updated

5 years ago
Depends on: 831585
(Assignee)

Updated

4 years ago
Assignee: general → nobody

Comment 7

26 days 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.

Updated

26 days ago
Status: NEW → RESOLVED
Last Resolved: 26 days ago
Resolution: --- → WORKSFORME

Updated

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