This is a confusing report, we have 

1.
==7219==AddressSanitizer: hard rss limit exhausted (3000Mb vs 3009Mb)
==7219==Process memory map follows:
	0x000000400000-0x000002eae000	/mnt/scratch0/clusterfuzz/slave-bot/builds/chromium-browser-libfuzzer_linux-release-asan_ae530a86793cd6b8b56ce9af9159ac101396e802/revisions/libfuzzer-linux-release-394032/v8_wasm_asmjs_fuzzer

and 

2. uaf with no crash stack.

==7219==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600000e540 at pc 0x00000049f543 bp 0x7ffb1aeacca0 sp 0x7ffb1aeac450
READ of size 57 at 0x60600000e540 thread T16777215
SCARINESS: 54 (multi-byte-read-heap-use-after-free)
    <empty stack>

0x60600000e540 is located 0 bytes inside of 57-byte region [0x60600000e540,0x60600000e579)
freed by thread T0 here:
    #0 0x4e000b in operator delete[](void*) (/mnt/scratch0/clusterfuzz/slave-bot/builds/chromium-browser-libfuzzer_linux-release-asan_ae530a86793cd6b8b56ce9af9159ac101396e802/revisions/libfuzzer-linux-release-394032/v8_wasm_asmjs_fuzzer+0x4e000b)
    #1 0x4f3a8b in operator()<unsigned char> buildtools/third_party/libc++/trunk/include/memory:2552:13

also report says unreproducible.

I can easily reproduce the OOM in the following way:

$ ASAN_OPTIONS=redzone=32:symbolize=1:detect_stack_use_after_return=1:alloc_dealloc_mismatch=0:detect_leaks=1:print_scariness=1:hard_rss_limit_mb=3000:check_malloc_usable_size=0:max_uar_stack_size_log=16:use_sigaltstack=1:handle_sigill=1:strict_memcmp=0:detect_container_overflow=1:quarantine_size_mb=10:handle_abort=1:coverage=0:detect_odr_violation=0:allocator_may_return_null=1:handle_segv=1:fast_unwind_on_fatal=1 ./v8_wasm_asmjs_fuzzer ../v8_wasm_asmjs_fuzzer -max_len=4365 -timeout=300 -max_total_time=3250 -print_final_stats=1 -seed=570031155



But cannot get the UaF.

Given that the target is multi-threaded, is it possible that:
1) several threads are running
2) libFuzzer detects hard rss limit exhaustion
3) libFuzzer starts to kill threads
4) one of the threads deallocated the object while dying
5) another thread (is not killed at the moment) uses that object -> UaF due to a race condition when killing threads

?

Yep, I am sorry :) 
This is a race in libFuzzer which makes it more or less impossible to 
use asan's hard_rss_limit_mb w/o occasionally hitting these use-after-free
after OOM. 

This is why I've recently added libFuzzer's own flag -rss_limit_mb=N (default, 2048). We should upgrade to the newest libFuzzer and remove asan's hard_rss_limit_mb from flags. 

The implementation of rss_limit_mb is not perfect either and I hope to improve it, but I am pretty sure it does not have this race any more. 

Max, can you do c#4.

New libFuzzer is rolling out: https://codereview.chromium.org/2004293003/

Tomorrow I will add '-rss_limit_mb=3000' flag and remove 'hard_rss_limit_mb' option. Cannot do it right now since libFuzzer doesn't run with unknown flags.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7bdf0a05e83ffc054cc2a966ff108b05d82f8cfd

commit 7bdf0a05e83ffc054cc2a966ff108b05d82f8cfd
Author: mmoroz <mmoroz@chromium.org>
Date: Tue May 24 23:03:12 2016

Roll LibFuzzer d05583b..feca8e5.

https://chromium.googlesource.com/chromium/llvm-project/llvm/lib/Fuzzer/+log/d05583b..feca8e5

TBR=kcc@chromium.org
BUG= 613888 

Review-Url: https://codereview.chromium.org/2004293003
Cr-Commit-Position: refs/heads/master@{#395722}

[modify] https://crrev.com/7bdf0a05e83ffc054cc2a966ff108b05d82f8cfd/DEPS
[modify] https://crrev.com/7bdf0a05e83ffc054cc2a966ff108b05d82f8cfd/third_party/libFuzzer/BUILD.gn

CF catched up new version. Added that flag (https://chromereviews.googleplex.com/436977013) and removed 'hard_rss_limit_mb' option from jobs env vars.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot