Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Assertion failure: IsMarkedOrAllocated(static_cast<Cell *>(*thingp)), at jsgc.cpp:4363

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
major
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: decoder, Assigned: billm)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Other Branch
x86_64
Linux
assertion, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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
Summary: IonMonkey: Assertion failure: IsMarkedOrAllocated(static_cast<Cell *>(*thingp)), at jsgc.cpp:4363 → Assertion failure: IsMarkedOrAllocated(static_cast<Cell *>(*thingp)), at jsgc.cpp:4363
No longer blocks: 724444
(Assignee)

Comment 2

6 years ago
Could you take a look at this, Terrence?
(Assignee)

Comment 3

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

Comment 5

6 years ago
I can reproduce. I'll take a look at it tomorrow.
Assignee: general → wmccloskey
(Assignee)

Comment 6

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

Comment 7

5 years ago
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.
(Assignee)

Comment 8

5 years ago
(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.
(Assignee)

Comment 9

5 years ago
I removed this assert, so I don't think this should trigger anymore.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

5 years ago
This was fixed by bug 748119.
(Reporter)

Comment 11

5 years ago
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/2e891e0db397
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.