The following testcase crashes on mozilla-central revision c7cc85e13f7a (run with --fuzzing-safe):
var s = new Set;
Created attachment 802284 [details]
[crash-signature] Machine-readable crash signature
I'm not hitting this one too often, but when I'm trying to isolate another, more important OOM bug, I often end up hitting this one.
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
user: Steve Fink
date: Mon May 20 12:59:55 2013 -0700
summary: Bug 872823 - implement oomAfterAllocations testing function
This iteration took 325.707 seconds to run.
I don't think that bug is the likely culprit, will try to investigate further today.
Created attachment 807447 [details] [diff] [review]
This is failing the alloc for the verifier data, which is not currently guarded against OOM. With GGC enabled, this migrates into the middle of Nursery::collect, where OOM is immediately fatal. To address the test failure on SM(ggc), I've added an AutoEnterOOMUnsafeRegion, which disables OOM debugging while live.
Comment on attachment 807447 [details] [diff] [review]
Review of attachment 807447 [details] [diff] [review]:
Sorry for the late review.
@@ +80,5 @@
> extern JS_PUBLIC_DATA(uint32_t) OOM_maxAllocations; /* set in builtins/TestingFunctions.cpp */
> extern JS_PUBLIC_DATA(uint32_t) OOM_counter; /* data race, who cares. */
> +/* Disable OOM testing in sections which are not OOM safe. */
> +class JS_PUBLIC_API(AutoEnterOOMUnsafeRegion)
There's no reason this needs to be part of the public API. Can you move it somewhere else? I think jsgc.h would be fine for now. Also, it should be in a the js:: namespace.
Right, OOM_max_allocations is extern, so we can set it from wherever. Thanks, Bill, that's much nicer!
*** Bug 915497 has been marked as a duplicate of this bug. ***