Out-of-memory in v8_json_parser_fuzzer |
|||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6080783256387584 Fuzzer: libFuzzer_v8_json_parser_fuzzer Job Type: libfuzzer_chrome_msan Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: v8_json_parser_fuzzer Sanitizer: memory (MSAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=525420:525446 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6080783256387584 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
,
Jan 4 2018
This bisect locally to 52cc5fe0d1b6c346e9de7829afd7c8c409869f5f ("Reland [Memory] Speculative fix for sanitizer flakiness."). Bill, do you see a reason why this would cause OOM issues? If not, please assign to Marja to check whether this OOM is expected / acceptable. Note that the test case just has 79kB in size.
,
Jan 4 2018
Oh, and it only fails after several runs. Reproduce with: out/tmp/v8_json_parser_fuzzer -timeout=25 -rss_limit_mb=2048 -runs=100 ~/Downloads/clusterfuzz-testcase-minimized-6080783256387584 Where the gn args for out/tmp are: enable_nacl = false ffmpeg_branding = "ChromeOS" is_debug = false is_msan = true msan_track_origins = 2 optimize_for_fuzzing = true pdf_enable_xfa = true proprietary_codecs = true use_libfuzzer = true use_prebuilt_instrumented_libraries = true
,
Jan 17 2018
Assigning to marja. My CL does two things - first, on POSIX systems, restricts random mmap addresses to a 1 Terabyte region in high memory, which is guaranteed not to interfere with sanitizer memory. Second, it adds a mutex to protect the RNG which is not thread safe. TSAN found a race (which would scramble some random numbers, making them extra-random I suppose). Here is how addresses are isolated on sanitizer builds (raw_addr is generated by the RNG): raw_addr &= 0x007fffff0000ULL; raw_addr += 0x7e8000000000ULL; I can't think of a reason why restricting the address space range (to a still enormous 1 Terabyte sub-range) would lead to OOM in these tests.
,
May 17 2018
,
Jul 2
I don't know anything about this particular fuzzer, so assigning back to actual fuzzer folks :)
,
Jul 16
MSan OOM on a huge input -- doesn't not make a lot of sense, but I'll add enforcement of the input length to avoid such crashes.
,
Jul 16
,
Jul 25
ClusterFuzz has detected this issue as fixed in range 575765:575774. Detailed report: https://clusterfuzz.com/testcase?key=6080783256387584 Fuzzer: libFuzzer_v8_json_parser_fuzzer Job Type: libfuzzer_chrome_msan Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: v8_json_parser_fuzzer Sanitizer: memory (MSAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=525420:525446 Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=575765:575774 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6080783256387584 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.
,
Jul 25
ClusterFuzz testcase 6080783256387584 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by brajkumar@chromium.org
, Jan 4 2018Labels: M-65