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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test asserts on mozilla-central revision 6785d3003414 (options -m -n -a):


gczeal(4);
test();
function test()
eval("with({}) let(x=[])(function(){#2=x})()");


Not s-s due to incremental GC relatedness.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

Another great test. I'm not sure how I missed this barrier.

Comment 2

[Brian Hackett [Laid off!]]

This field didn't exist before objshrink.  I must be missing something, as I didn't think that incremental barriers were needed at all for fields that are only written at the point of object creation (as the function's environment is).  I can see how the HeapPtr is needed for generational write barriers though, are the gczeal(4) asserts stronger than is required for incremental GC?

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(In reply to Brian Hackett (:bhackett) from comment #2)
> I must be missing something, as I
> didn't think that incremental barriers were needed at all for fields that
> are only written at the point of object creation (as the function's
> environment is).

There is a write in CloneFunctionObjectIfNotSingleton that is on a pre-existing object.

The verifier currently checks only what's needed for incremental GC. Terrence is working on checks for generational.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3a190f6b9ee3

Comment 5

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/3a190f6b9ee3

Comment 6

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug708805.js.