As you can see, there are a lot of active intermittent oranges caused by this test (or maybe set of tests). These are just the ones I found with a bit of searching. I'm not sure what the way to fix this is. Can we add forced GCs in between the tests in this directory, or additional time to let things get collected?

What am I being asked for info on? These tests should just be chopped down in size (upstream) -- they don't really need to test *so* many permutations. This would greatly reduce runtime too. See bug 859087. I could do this when I next have free time (mid-July).

Thanks Aryeh, just wanted your input as test author.

This test is causing 7% of Windows M2 runs to blow out their log. philor is working around this by disabling some OOM log messages the CC is spamming.

A medium term fix I'm working on will add the warnings back, but only once instead of a million times, but this test really needs to be fixed in some manner.

As a short term fix, after it failed by shoving an OOM assertion into another test's count of unexpected assertions, I disabled it on Windows in https://hg.mozilla.org/mozilla-central/rev/a81bece350a1, leaving Ms2ger to deal with the problem of only being able to disable a test on a platform by editing a DO NOT EDIT generated file.

(In reply to Phil Ringnalda (:philor) from comment #5) > As a short term fix, after it failed by shoving an OOM assertion into > another test's count of unexpected assertions, I disabled it on Windows in > https://hg.mozilla.org/mozilla-central/rev/a81bece350a1, leaving Ms2ger to > deal with the problem of only being able to disable a test on a platform by > editing a DO NOT EDIT generated file.

Gave it the old heave-ho on aurora too in https://hg.mozilla.org/releases/mozilla-aurora/rev/edbdb962f5fe, since disabling a test is a clear a=test-only and deleting a couple of warnings is not.

Looks like test_Range-set has started failing about once a day due to OOM, in bug 894030.

Fixed by bug 933072. Hooray for roc!