The following test asserts on mozilla-central revision 6785d3003414 (options -m -n -a):
Not s-s due to incremental GC relatedness.
Created attachment 580282 [details] [diff] [review]
Another great test. I'm not sure how I missed this barrier.
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?
(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.
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug708805.js.