The following testcase asserts on ionmonkey revision ca97bbcd6b90 (run with --ion -n -m), tested on 64 bit: gczeal(4); function TestCase(n, d, e, a) {} TestCase.prototype.dump = function () {}; TestCase.prototype.testFailed = (function TestCase_testFailed() { }); try { try { } catch(ex1) { } } catch(ex) { } options.initvalues = {}; var optionNames = options().split(','); var optionsframe = {}; try { optionsClear(); } catch(ex) { } var lfcode = new Array(); lfcode.push("\ try { } catch (exception) { }\ try { } catch (exception) { }\ try { } catch (exception) { }\ try { } catch (actual) { }\ var props = {};\ function test(which) {\ var g = newGlobal(\"new-compartment\");\ function addDebugger(g, i) {\ var dbg = Debugger(g);\ dbg.onDebuggerStatement = function (frame) { };\ }\ for (var i = 0; i < 3; i++) {\ addDebugger(g, i);\ }\ g.eval(\"debugger;\");\ }\ for (var j = 0; j < 3; j++) test(j);\ "); while (true) { var file = lfcode.shift(); if (file == undefined) { break; } try { evaluate(file); } catch (lfVare) { } }

This assert triggers for me without any shell arguments, and seems to trigger on m-c too

Could you take a look at this, Terrence?

David, what m-c revision did you test with? I'm not seeing this on tip.

(In reply to Bill McCloskey (:billm) from comment #3) > David, what m-c revision did you test with? I'm not seeing this on tip. changeset: 87454:5e756e59a794

I can reproduce. I'll take a look at it tomorrow.

This is a false positive from the barrier verifier. It happens because TraceRuntime doesn't normally traverse debugger objects, since that happens from Debugger::markAllIteratively. So, from the write barrier verifier's perspective, a Debugger object is appearing out of nowhere when it gets used by some code. I'm going to put this on hold for a little while.

What is the status here? I do have another test with this assertion, but without this one resolved, it's hard to say if it's the same thing.

(In reply to Christian Holler (:decoder) from comment #7) > What is the status here? I do have another test with this assertion, but > without this one resolved, it's hard to say if it's the same thing. I'll try to fix it soon. If the other test case doesn't involve debugger objects, then it's different than this.

I removed this assert, so I don't think this should trigger anymore.

This was fixed by bug 748119.

Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/2e891e0db397