Assertion failure: cx->iterValue.isMagic(JS_NO_ITER_VALUE), at js/src/jsinterp.cpp:340
RESOLVED
WORKSFORME
Status
()
People
(Reporter: past, Unassigned)
Tracking
Firefox Tracking Flags
(Not tracked)
Details
Attachments
(1 attachment)
93.67 KB,
text/plain
|
Details |
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.
Blocks: 815241
(Assignee) | ||
Updated•5 years ago
|
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
You need to log in
before you can comment on or make changes to this bug.
Description
•