Closed Bug 880776 Opened 11 years ago Closed 11 years ago

GenerationalGC: Assertion failure: !IsInsideNursery(rt, obj), at ion/VMFunctions.cpp:573

Categories

(Core :: JavaScript Engine, defect)

All
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: decoder, Assigned: terrence)

References

Details

(Keywords: assertion, testcase, Whiteboard: [jsbugmon:ignore])

Attachments

(2 files)

The following testcase asserts on mozilla-central built with --enable-exact-rooting --enable-gcgenerational, revision 9ca690835a5e (run with ):


gczeal(11);
var otherGlobal = newGlobal('new-compartment');
function test(str, arg, result)
{
    var fun = new Function('x', str);
    var code = "(function (x) { " + str + " })";
    var c = clone(otherGlobal.evaluate(code, {compileAndGo: false}));
    assertEq(c.toSource(), eval(code).toSource());
}
test('return let (y) x;');
test('return let (x) "" + x;', 'unicorns', 'undefined');
test('return let (y = x) (y++, "" + y);', 'unicorns', 'NaN');
test('return let (y = 1) (y = x, y);');
test('return let ([] = x) x;');
test('return let ([, ] = x) x;');
test('return let ([, , , , ] = x) x;');
test('return let ([[]] = x) x;');
test('return let ([[[[[[[[[[[[[]]]]]]]]]]]]] = x) x;');
test('return let ([[], []] = x) x;');
test('return let ([[[[]]], [], , [], [[]]] = x) x;');
jsfunfuzz got this too.
Hardware: x86 → All
Attached patch v0Splinter Review
The jitcode version of IsInsideNursery does not know about the post-barrier verifier, so we can end up calling the PostBarrier VMFunction on edges which are only virtually "in the nursery". We can simply filter these edges after the API call instead of before at the cost of a bit of performance when running the post-barrier verifier.
Assignee: general → terrence
Status: NEW → ASSIGNED
Attachment #759934 - Flags: review?(bhackett1024)
Comment on attachment 759934 [details] [diff] [review]
v0

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

Sorry for the delay.

::: js/src/ion/VMFunctions.cpp
@@ +573,5 @@
> +#ifdef JS_GC_ZEAL
> +    /* The jitcode version of IsInsideNursery does not know about the verifier. */
> +    if (rt->gcVerifyPostData && rt->gcVerifierNursery.isInside(obj))
> +        return;
> +#endif

What does having objects that are only "virtually" in the nursery allow, now that we have an actual nursery?
Attachment #759934 - Flags: review?(bhackett1024) → review+
(In reply to Brian Hackett (:bhackett) from comment #4)
>
> What does having objects that are only "virtually" in the nursery allow, now
> that we have an actual nursery?

The only advantage of this is that we don't have to worry about objects dying because of missing barriers. My thinking was that for browser builds we would want to report errors rather than crashing so that we could fix more than one error between recompiles. Given how many random bugs this scheme has caused, not to mention extra complexity, I'm starting to think this feature is probably not worth the hassle. We need to revisit the verifier anyway to make it faster before it will be useful for analysing the browser: removing the set would be helpful there too.

I think we should probably check this in as is for now and I will try to rewrite the verifier as soon as GGC is green on inbound.
https://hg.mozilla.org/mozilla-central/rev/f9c790ff5706
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: