The following testcase asserts on mozilla-central revision 4fddb9923ef0 (run with --ion-eager): function printBugNumber (num) { BUGNUMBER = num; } gcslice(0) schedulegc(this); gcslice(1); var BUGNUMBER = ("one"); printBugNumber();

S-s due to GC-related assertion.

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 113229:6ba78023b367 user: Brian Hackett date: Wed Nov 14 06:46:31 2012 -0800 summary: Eagerly generate a single copy of Ion stubs and wrappers, bug 786146. r=dvander This iteration took 119.548 seconds to run.

This assertion is now at line 1884. It looks like MarkFromIon is being called on a compartment that doesn't need a barrier. The description in bug 786146 says: "The stubs are allocated in the atoms compartment and, once created, are not collected until the runtime is destroyed." ...so maybe barriers are being used on the stubs, and maybe that isn't needed any more because they are in the atoms compartment?

The bisection here is wrong, the assert that is failing was added by bug 812235 to fix a bogus assert that was tripping because of the revision being blamed here. Bug 812235 added a new assert to try to capture better the assert that was tripping --- that we only try to incrementally mark things in compartments that are being collected --- but even that new assert is wrong, as during an IGC we can try to incrementally mark atoms even if the atoms compartment is being collected. The attached patch just removes the assert.

Bogus assert, not s-s.

(In reply to Brian Hackett (:bhackett) from comment #4) > we can try to incrementally mark atoms even if the atoms compartment is being collected. ... even if the atoms compartment is *not* being collected. Need to proofread more...

Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929