function m() { for (var j = 0; j < 99; ++j) { for (var k = 0; k < 99; ++k) { try { undefined()() } catch (e) {} } } } m() m() m() m() for (var j = 0; j < 99; ++j) { for (var k = 0; k < 99; ++k) { try { gcslice(1)() } catch (e) {} } } asserts js debug shell on m-c changeset 5bd6e09f074e with --ion-offthread-compile=off --ion-eager at Assertion failure: state() == IDLE, at jsgc.cpp. Debug configure flags: CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/3f395d9d894a user: Terrence Cole date: Fri Aug 22 14:28:56 2014 -0700 summary: Bug 1057563 - There is no need to sync with the GC helper thread between slices; r=jonco Terrence, is bug 1057563 a possible regressor? (Setting s-s because this is related to gc)

This is seen in the wild with Nightly on bughunter as well.

This is caused by the fix for bug 1057563. The patch (which I reviewed) removes the call to waitBackgroundSweepOrAllocEnd() when starting an incremental GC slice that is not the first slice, on the grounds that background sweeping cannot be running at this time. I missed the "OrAlloc" part, and background allocation can indeed be running. The fix is either to backout that patch and live with the small occasional pause here or disable background allocation during incremental GC. Terrence what do you think?

This is likely sec-critical. I see lots of GC crashes that sometimes pop up this assertion when reducing. Crashes include patterns like 0x4b4b4b4b so it's probably using memory it shouldn't be using.

Gah, I also forgot about background alloc! I think the optimal solution here would be to make the background alloc thread detect GC, return the memory and give up in that case (rather than waiting, as we don't want to deadlock when doing concurrent operation in the GC). For now let's just back out.

And backed out: https://hg.mozilla.org/integration/mozilla-inbound/rev/f026869ee548

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 790f41c631cc).

(In reply to Terrence Cole [:terrence] from comment #5) > And backed out: > https://hg.mozilla.org/integration/mozilla-inbound/rev/f026869ee548 Resolving FIXED by the backout.

JSBugMon: This bug has been automatically verified fixed.

Should you land this test? Given the number of dupes of this issue it seems like it would be worth having.

Good idea! https://hg.mozilla.org/integration/mozilla-inbound/rev/1a45edebf719

Does this impact ESR?

No, this was a regression that was backed out.