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

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
6 years ago
10 months ago

People

(Reporter: past, Unassigned)

Tracking

Trunk
x86
macOS
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.)
(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

6 years ago
Blocks: 806820

Updated

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.

Updated

10 months ago
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → WORKSFORME

Updated

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