Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

Automatically adding ccs based on suspected regression changelists:

[heap] Externalize mark bitmap. by hpayer@chromium.org - https://chromium.googlesource.com/v8/v8/+/17890f67fbd1cafa33f472559f09a1fad70993ce

[base] Introduce MutexGuard as typedef for LockGuard<Mutex> by clemensh@chromium.org - https://chromium.googlesource.com/v8/v8/+/75b5666175fd2c445503dda59f07b2a892a3f022

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

Wow, surprising. I don't see how this could leak since this would imply all other dynamically fields in MemoryChunk would leak as well. 

Will try to reproduce.

Trying to repro: prodaccess && /google/data/ro/teams/clusterfuzz-tools/releases/clusterfuzz reproduce 5741065380036608
Reproducing...
Running: ASAN_SYMBOLIZER_PATH="/usr/local/google/home/hpayer/.pex/code/d9b4de40f5d9a394538fddf2432fadb9a660a2d3/clusterfuzz/resources/llvm-symbolizer" DISPLAY=":0.0" ASAN_OPTIONS="redzone=16:strict_string_check=1:print_suppressions=0:strict_memcmp=1:allow_user_segv_handler=0:max_uar_stack_size_log=16:handle_sigfpe=1:handle_sigbus=1:detect_stack_use_after_return=1:alloc_dealloc_mismatch=0:print_scariness=1:allocator_may_return_null=1:quarantine_size_mb=256:detect_odr_violation=0:handle_sigill=1:allocator_release_to_os_interval_ms=500:use_sigaltstack=1:fast_unwind_on_fatal=1:detect_leaks=1:handle_segv=1:handle_abort=1:check_malloc_usable_size=0:detect_container_overflow=1:symbolize=1:print_summary=1" /usr/local/google/home/hpayer/chromium/src/out/clusterfuzz_5741065380036608/feature_policy_fuzzer /usr/local/google/home/hpayer/.clusterfuzz/cache/testcases/5741065380036608_testcase/fuzz-0 feature_policy_fuzzer
======================= INFO =========================
This binary is built for AFL-fuzz.
To run the target function on individual input(s) execute this:
  /usr/local/google/home/hpayer/chromium/src/out/clusterfuzz_5741065380036608/feature_policy_fuzzer < INPUT_FILE
or
  /usr/local/google/home/hpayer/chromium/src/out/clusterfuzz_5741065380036608/feature_policy_fuzzer INPUT_FILE1 [INPUT_FILE2 ... ]
To fuzz with afl-fuzz execute this:
  afl-fuzz [afl-flags] /usr/local/google/home/hpayer/chromium/src/out/clusterfuzz_5741065380036608/feature_policy_fuzzer [-N]
afl-fuzz will run N iterations before re-spawning the process (default: 1000)
======================================================
Reading 0 bytes from /usr/local/google/home/hpayer/.clusterfuzz/cache/testcases/5741065380036608_testcase/fuzz-0
Execution successful
Reading 1058734688 bytes from feature_policy_fuzzer
New crash type: 
New crash state:
  

Original crash type: 
Original crash state:
  

The stacktrace seems similar to the original stacktrace.
Since you've reproduced the crash correctly, there are some tricks that might help you move faster:
- In case of fixing the crash, you can use `--current` to run on tip-of-tree (or, in other words, avoid git-checkout).
- You can save time by using `--skip-deps` to avoid `gclient sync`, `gclient runhooks`, and other dependency installations in subsequential runs.
- You can debug with gdb using `--enable-debug`.
- You can modify args.gn and arguments using `--edit-mode`.

Detailed log of this run can be found in: /usr/local/google/home/hpayer/.clusterfuzz/logs/output.log


Is this expected to work? Clemens?

ClusterFuzz testcase 5741065380036608 appears to be flaky, updating reproducibility label.

I had several cases where the reproduce tool did not work. I often fall back to doing it manually.
But since ClusterFuzz also found this to not reproduce any more, let's just close this issue.

Sounds good. Let's close since it does not reproduce anymore.