Last Comment Bug 914614 - Crash [@ js::gc::StartVerifyPreBarriers] with OOM
: Crash [@ js::gc::StartVerifyPreBarriers] with OOM
: crash, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Linux
-- critical (vote)
: mozilla27
Assigned To: Terrence Cole [:terrence]
: general
: Jason Orendorff [:jorendorff]
: 915497 (view as bug list)
Depends on:
Blocks: langfuzz 912928 872823
  Show dependency treegraph
Reported: 2013-09-10 06:22 PDT by Christian Holler (:decoder)
Modified: 2013-09-27 19:18 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

[crash-signature] Machine-readable crash signature (507 bytes, text/plain)
2013-09-10 06:24 PDT, Christian Holler (:decoder)
no flags Details
fuzz_914614-v0.diff (4.43 KB, patch)
2013-09-19 14:42 PDT, Terrence Cole [:terrence]
wmccloskey: review+
Details | Diff | Splinter Review

Description User image Christian Holler (:decoder) 2013-09-10 06:22:26 PDT
The following testcase crashes on mozilla-central revision c7cc85e13f7a (run with --fuzzing-safe):

var s = new Set;
Comment 1 User image Christian Holler (:decoder) 2013-09-10 06:24:15 PDT
Created attachment 802284 [details]
[crash-signature] Machine-readable crash signature
Comment 2 User image Christian Holler (:decoder) 2013-09-10 06:25:44 PDT
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.
Comment 3 User image Christian Holler (:decoder) 2013-09-10 11:16:10 PDT
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.
Comment 4 User image Terrence Cole [:terrence] 2013-09-10 12:08:17 PDT
I don't think that bug is the likely culprit, will try to investigate further today.
Comment 5 User image Terrence Cole [:terrence] 2013-09-19 14:42:28 PDT
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 6 User image Bill McCloskey (:billm) 2013-09-24 13:50:19 PDT
Comment on attachment 807447 [details] [diff] [review]

Review of attachment 807447 [details] [diff] [review]:

Sorry for the late review.

::: js/public/Utility.h
@@ +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.
Comment 7 User image Terrence Cole [:terrence] 2013-09-27 10:47:06 PDT
Right, OOM_max_allocations is extern, so we can set it from wherever. Thanks, Bill, that's much nicer!
Comment 8 User image Terrence Cole [:terrence] 2013-09-27 10:48:07 PDT
*** Bug 915497 has been marked as a duplicate of this bug. ***
Comment 9 User image Wes Kocher (:KWierso) 2013-09-27 19:18:47 PDT

Note You need to log in before you can comment on or make changes to this bug.