Closed Bug 713226 Opened 13 years ago Closed 12 years ago

Assertion failure: (static_cast<Cell *>(thing)->isMarked()), at jsgc.cpp:3556

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla13

People

(Reporter: decoder, Assigned: billm)

Details

(Keywords: assertion, testcase)

Attachments

(1 file)

The following test asserts on larch branch (incremental GC) revision c5b90ea7e475 (options -m -n -a):


gczeal(4);
var optionNames = options().split(',');
  for (var i = 0; i < optionNames.length; i++)
    var optionName = optionNames[i];
      options(optionName);
evaluate("\
function addDebug(g, id) {\
    var debuggerGlobal = newGlobal('new-compartment');\
    debuggerGlobal.debuggee = g;\
    debuggerGlobal.id = id;\
    debuggerGlobal.print = function (s) { (g) += s; };\
    debuggerGlobal.eval('var dbg = new Debugger(debuggee);dbg.onDebuggerStatement = function () { print(id); debugger; };');\
    return debuggerGlobal;\
}\
var base = newGlobal('new-compartment');\
var top = base;\
for (var i = 0; i < 8; i++ )\
    top = addDebug(top, i);\
base.eval('debugger;');\
");
I can't find this rev on the larch branch. Is it a typo?

I tried this testcase on different revisions. I found one where it asserts with the |started| assertion that was fixed in bug 713214. I couldn't get an isMarked assertion. Can you look at this one again, Christian?
The revision is a mozilla-central revision so I checked this again and the assertion is indeed on mozilla-central. So the mistake I made is specifying the wrong branch. I confirmed this being on m-c revision d98fbf3cbd71.
Version: Other Branch → Trunk
Summary: [IncrementalGC] Assertion failure: (static_cast<Cell *>(thing)->isMarked()), at jsgc.cpp:3556 → Assertion failure: (static_cast<Cell *>(thing)->isMarked()), at jsgc.cpp:3556
This also involves a debugger, Ccing jsdbg2 devs.
I'm pretty sure this is unrelated to the debugger. It has to do with TI and call objects.
Attached patch patchSplinter Review
I guess we don't have type information for JSOP_SETNAME opcodes.
Attachment #592892 - Flags: review?(bhackett1024)
Comment on attachment 592892 [details] [diff] [review]
patch

Review of attachment 592892 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/methodjit/Compiler.cpp
@@ +5635,4 @@
>  #ifdef JSGC_INCREMENTAL_MJ
> +    /* Write barrier. We only have type information for JSOP_SETPROP. */
> +    if (cx->compartment->needsBarrier() &&
> +        (!types || op != JSOP_SETPROP || types->propertyNeedsBarrier(cx, id)))

This should test for op == JSOP_SETNAME, so it does not slow path JSOP_SETMETHOD.  (I think SETMETHOD will always hit propertyNeedsBarrier anyways, but that's a little subtle).
Attachment #592892 - Flags: review?(bhackett1024) → review+
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/71f5bf4df2f6 - one of the six in that push was crashing in js::gc::Mark<JSString>
Target Milestone: mozilla13 → ---
https://hg.mozilla.org/integration/mozilla-inbound/rev/3500272283ed

After I pushed I noticed that I forgot to address Brian's review comment. When I made the obvious change, the test case started to fail again. I'll look into this now.
Target Milestone: --- → mozilla13
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug713226.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: