SerializedScriptValueFuzzer: Yield to the run loop to allow GC tasks to run.

SerializedScriptValueFuzzer: Yield to the run loop to allow GC tasks to run.

The Blink garbage collector (Oilpan) relies on control periodically being
yielded to the run loop to work efficiently. Previously, the fuzzer wasn't
doing this, leading to a reduction in fuzzing speed and an increase in memory
usage. Unit tests typically do not last long enough for this to be an issue.

By periodically yielding to the run loop, the fuzzer has more stable
performance characteristics over long runs. Every 2048 iterations was chosen
as a slightly-tweaked heuristic, to balance between the cost of yielding to
the run loop and the expense of letting the heap grow too much.

BUG=148757
Committed: https://crrev.com/0f23ef667b5cbad5c0b1c3c2f31fd98e52535b78
Cr-Commit-Position: refs/heads/master@{#426031}

[jbroman, 2016-10-17 22:59:02]

The CQ bit was checked by jbroman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 22:59:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-17 23:50:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-17 23:50:26]

Dry run: This issue passed the CQ dry run.

[jbroman, 2016-10-17 23:52:26]

jbroman@chromium.org changed reviewers:
+ haraken@chromium.org, kcc@chromium.org

[haraken, 2016-10-17 23:53:54]

LGTM

[inferno, 2016-10-18 00:18:57]

inferno@chromium.org changed reviewers:
+ ahaas@chromium.org, inferno@chromium.org, mmoroz@chromium.org,
ochang@chromium.org

[inferno, 2016-10-18 00:18:58]

lgtm.

Do we need to do something similar for other v8 libfuzzers, like wasm*, etc ?

[jbroman, 2016-10-18 03:22:56]

On 2016/10/18 at 00:18:58, inferno wrote:
> lgtm.
> 
> Do we need to do something similar for other v8 libfuzzers, like wasm*, etc ?

The issues I was seeing here involved Blink's GC (and its interactions with
V8's), so I don't have any reason to believe that pure V8 fuzzers (that don't
use Blink) would be affected.

[inferno, 2016-10-18 03:27:58]

On 2016/10/18 03:22:56, jbroman wrote:
> On 2016/10/18 at 00:18:58, inferno wrote:
> > lgtm.
> > 
> > Do we need to do something similar for other v8 libfuzzers, like wasm*, etc
?
> 
> The issues I was seeing here involved Blink's GC (and its interactions with
> V8's), so I don't have any reason to believe that pure V8 fuzzers (that don't
> use Blink) would be affected.

Thanks!

[jbroman, 2016-10-18 20:07:21]

The CQ bit was checked by jbroman@chromium.org

[commit-bot: I haz the power, 2016-10-18 20:07:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-18 20:15:48]

Committed patchset #1 (id:1)

[inferno, 2016-10-18 20:54:52]

On 2016/10/18 20:15:48, commit-bot: I haz the power wrote:
> Committed patchset #1 (id:1)

Hoping that it resolves the current coverage problem for this fuzzer. Need to
check back stats tmrw to confirm -
https://cluster-fuzz.appspot.com/fuzzerstats?fuzzer_name=all&job_type=libfuzz....
Right now corpus merge fails on OOM.

[10-17 19:35:06] 0 corpus files uploaded for v8_serialized_script_value_fuzzer.
[10-17 19:35:18] Error: Corpus pruning failed: Corpus pruning failed with
output: INFO: Seed: 1849519124
INFO: Loaded 0 modules (0 guards):
INFO: -max_len is not provided, using 1048576
Loaded 1024/1177 files from
/mnt/scratch0/clusterfuzz/slave-bot/inputs/fuzzer-testcases-disk/v8_serialized_script_value_fuzzer_initial_corpus
=== Merging extra 1177 units
ASAN:DEADLYSIGNAL
=================================================================
==28692==ERROR: AddressSanitizer: ILL on unknown address 0x00000b0b632e (pc
0x00000b0b632e bp 0x7ffe72a91cf0 sp 0x7ffe72a91ce0 T0)
SCARINESS: 10 (signal)
    #0 0xb0b632d in blink::reportOOMErrorInMainThread(char const*, bool)
third_party/WebKit/Source/bindings/core/v8/V8Initializer.cpp:108:3
    #1 0x7b7059 in v8::Utils::ReportOOMFailure(char const*, bool)
v8/src/api.cc:389:5
    #2 0x7b6fbc in v8::internal::V8::FatalProcessOutOfMemory(char const*, bool)
v8/src/api.cc:352:3
    #3 0x121f8ef in v8::internal::Factory::NewRawOneByteString(int,
v8::internal::PretenureFlag) v8/src/factory.cc:428:3
    #4 0x1b6cee7 in __RT_impl_Runtime_SparseJoinWithSeparator
v8/src/runtime/runtime-strings.cc:477:45
    #5 0x1b6cee7 in v8::internal::Runtime_SparseJoinWithSeparator(int,
v8::internal::Object**, v8::internal::Isolate*)
v8/src/runtime/runtime-strings.cc:412
    #6 0x7f29af9843a6  (<unknown module>)
    #7 0x7f29afa8a1cd  (<unknown module>)
    #8 0x7f29afa87f7f  (<unknown module>)
    #9 0x7f29afa8e45e  (<unknown module>)
    #10 0x7f29afa8744c  (<unknown module>)
    #11 0x7f29af9d75e2  (<unknown module>)
    #12 0x7f29af9a7260  (<unknown module>)

[jbroman, 2016-10-18 20:57:39]

On 2016/10/18 at 20:54:52, inferno wrote:
> On 2016/10/18 20:15:48, commit-bot: I haz the power wrote:
> > Committed patchset #1 (id:1)
> 
> Hoping that it resolves the current coverage problem for this fuzzer. Need to
check back stats tmrw to confirm -
https://cluster-fuzz.appspot.com/fuzzerstats?fuzzer_name=all&job_type=libfuzz....
Right now corpus merge fails on OOM.
> 
> [10-17 19:35:06] 0 corpus files uploaded for
v8_serialized_script_value_fuzzer.
> [10-17 19:35:18] Error: Corpus pruning failed: Corpus pruning failed with
output: INFO: Seed: 1849519124
> INFO: Loaded 0 modules (0 guards):
> INFO: -max_len is not provided, using 1048576
> Loaded 1024/1177 files from
/mnt/scratch0/clusterfuzz/slave-bot/inputs/fuzzer-testcases-disk/v8_serialized_script_value_fuzzer_initial_corpus
> === Merging extra 1177 units
> ASAN:DEADLYSIGNAL
> =================================================================
> ==28692==ERROR: AddressSanitizer: ILL on unknown address 0x00000b0b632e (pc
0x00000b0b632e bp 0x7ffe72a91cf0 sp 0x7ffe72a91ce0 T0)
> SCARINESS: 10 (signal)
>     #0 0xb0b632d in blink::reportOOMErrorInMainThread(char const*, bool)
third_party/WebKit/Source/bindings/core/v8/V8Initializer.cpp:108:3
>     #1 0x7b7059 in v8::Utils::ReportOOMFailure(char const*, bool)
v8/src/api.cc:389:5
>     #2 0x7b6fbc in v8::internal::V8::FatalProcessOutOfMemory(char const*,
bool) v8/src/api.cc:352:3
>     #3 0x121f8ef in v8::internal::Factory::NewRawOneByteString(int,
v8::internal::PretenureFlag) v8/src/factory.cc:428:3
>     #4 0x1b6cee7 in __RT_impl_Runtime_SparseJoinWithSeparator
v8/src/runtime/runtime-strings.cc:477:45
>     #5 0x1b6cee7 in v8::internal::Runtime_SparseJoinWithSeparator(int,
v8::internal::Object**, v8::internal::Isolate*)
v8/src/runtime/runtime-strings.cc:412
>     #6 0x7f29af9843a6  (<unknown module>)
>     #7 0x7f29afa8a1cd  (<unknown module>)
>     #8 0x7f29afa87f7f  (<unknown module>)
>     #9 0x7f29afa8e45e  (<unknown module>)
>     #10 0x7f29afa8744c  (<unknown module>)
>     #11 0x7f29af9d75e2  (<unknown module>)
>     #12 0x7f29af9a7260  (<unknown module>)

Hopefully. The tricky thing is, it's possible (and legal) for an input to
request a large buffer allocation, and doing a full GC of everything on every
input is expensive enough that it slows things to ~1 run/s.

[commit-bot: I haz the power, 2016-10-21 13:02:32]

Description was changed from

==========
SerializedScriptValueFuzzer: Yield to the run loop to allow GC tasks to run.

The Blink garbage collector (Oilpan) relies on control periodically being
yielded to the run loop to work efficiently. Previously, the fuzzer wasn't
doing this, leading to a reduction in fuzzing speed and an increase in memory
usage. Unit tests typically do not last long enough for this to be an issue.

By periodically yielding to the run loop, the fuzzer has more stable
performance characteristics over long runs. Every 2048 iterations was chosen
as a slightly-tweaked heuristic, to balance between the cost of yielding to
the run loop and the expense of letting the heap grow too much.

BUG=148757
==========

to

==========
SerializedScriptValueFuzzer: Yield to the run loop to allow GC tasks to run.

The Blink garbage collector (Oilpan) relies on control periodically being
yielded to the run loop to work efficiently. Previously, the fuzzer wasn't
doing this, leading to a reduction in fuzzing speed and an increase in memory
usage. Unit tests typically do not last long enough for this to be an issue.

By periodically yielding to the run loop, the fuzzer has more stable
performance characteristics over long runs. Every 2048 iterations was chosen
as a slightly-tweaked heuristic, to balance between the cost of yielding to
the run loop and the expense of letting the heap grow too much.

BUG=148757

Committed: https://crrev.com/0f23ef667b5cbad5c0b1c3c2f31fd98e52535b78
Cr-Commit-Position: refs/heads/master@{#426031}
==========

[commit-bot: I haz the power, 2016-10-21 13:02:33]

Patchset 1 (id:??) landed as
https://crrev.com/0f23ef667b5cbad5c0b1c3c2f31fd98e52535b78
Cr-Commit-Position: refs/heads/master@{#426031}