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 assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/f46a92c2a8c716c6ad49ea61c4283bdffba3e52a ([heap] MC: Parallel marking for the atomic pause).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

+marja: Have you seen similar timeouts on this fuzzer before? I am wondering whether this is an actionable report here.

This is not my fuzzer so I wouldn't know :)

We barely run out of time for this one. Root scanning is crazy expensive with the gn flag optimize_for_fuzzing.

Not sure we can do anything here other than use a different timeout limit.

Un-assinging to kick off triage process.

This is not a regression. This input is very slow since several months. Note that it's 124kB of complex input.

I suggest to reduce the input size limit for that fuzzer.

+mmoroz for guidance how to do that.

Sure, let's do that! What could be a reasonable length? 16KB maybe? Or less?

Probably even 4kB is enough to find all parser bugs.
Marja?

Just tried in a Release build (is_debug=false use_goma=true is_component_build=true use_libfuzzer=true is_asan=true is_lsan=true), and it still takes 32 seconds on my workstation.
Without is_asan and is_lsan, it's still 12 seconds.

Assigning to Marja to find out if this huge runtime is expected for this input. Feel free to reassign if you feel not responsible :)

Regarding a good input limit for that fuzzer: I looked at the last 10 bugs, all of them are <= 1kB (mostly 10-30 bytes). So I think 4kB will work fine.
Marja, can you think of a bug which would not be found with <=4kB input?

Umm, this is not my fuzzer... my fuzzer is libFuzzer_javascript_parser_proto_fuzzer and I'm not maintaining this one.

Looks like the timeout is happening just because the input is too long, e.g. I shrank out roughly 3/4th of it and the time to process the input reduced by 5x.

Uploaded a CL: https://chromium-review.googlesource.com/c/v8/v8/+/1136986

ClusterFuzz has detected this issue as fixed in range 575386:575393.

Detailed report: https://clusterfuzz.com/testcase?key=4697376590397440

Fuzzer: libFuzzer_v8_script_parser_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  v8_script_parser_fuzzer
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=506409:506451
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=575386:575393

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4697376590397440

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4697376590397440 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.