Null-dereference READ in bool base::ContainsKey<std::__1::map<std::__1::basic_string<char, std::__1::char |
|||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5759655978205184 Fuzzer: libFuzzer_clear_site_data_fuzzer Job Type: mac_libfuzzer_chrome_asan Platform Id: mac Crash Type: Null-dereference READ Crash Address: 0x000000000020 Crash State: bool base::ContainsKey<std::__1::map<std::__1::basic_string<char, std::__1::char base::CommandLine::HasSwitch content::ClearSiteDataThrottle::ParseHeader Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=606416:606443 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5759655978205184 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
,
Nov 14
Automatically adding ccs based on OWNERS file / target commit history. If this is incorrect, please add ClusterFuzz-Wrong label.
,
Nov 15
Predator and CL could not provide any possible suspects. Using Code Search for the file, "clear_site_data_throttle.cc" suspecting the below Cl might have caused this issue Suspect CL: https://chromium.googlesource.com/chromium/src/+/fdbb7e9d9e56bbcec88157b539f0418c1fb744fa chongz@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks!
,
Dec 1
ClusterFuzz testcase 5759655978205184 appears to be flaky, updating reproducibility label.
,
Dec 1
Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ClusterFuzz
, Nov 14Labels: Test-Predator-Auto-Components