CompositorProxy somehow producing invalid zero elementId |
||||||
Issue descriptionDetailed report: https://cluster-fuzz.appspot.com/testcase?key=5758043410399232 Fuzzer: libfuzzer_v8_serialized_script_value_fuzzer Job Type: libfuzzer_chrome_asan_debug Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (HashTableKeyChecker< HashTranslator, KeyTraits, HashFunctions::safeToCompareToE blink::WeakIdentifierMap<blink::Node, int>::lookup blink::DOMNodeIds::nodeForId Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan_debug&range=424448:424514 Minimized Testcase (0.01 Kb): https://cluster-fuzz.appspot.com/download/AMIfv97mJB6_6HY5JMDOWLZK2NAtn96MfHKLzeJltQj7BtguhBMOYJlzX_17RGH9UEnC07RYzbX-3BxyfQREb45lrhodN96SbEctUoWtEktT7dLaNs_yYnCoUGjz2G24V6gVYx7N07MkTt9CGtJB4LJYjmwDufH5yA?testcase_id=5758043410399232 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.
,
Oct 25 2016
tkent@, if you think this is not security-related, please remove the security labels.
,
Oct 25 2016
yutak@, can you take a look at this? I don't understand why ClusterFuzz thought it was a security issue.
,
Oct 25 2016
Thanks tkent, removing security labels. We need to change all ASSERT_WITH_SECURITY_IMPLICATIONS to SECURITY_DCHECK, since we can't distinguish between ASSERT_WITH_SECURITY_IMPLICATIONS and normal ASSERT in debug builds.
,
Oct 26 2016
The ClusterFuzz page says: "Reproducible: No". Should I still take a look? BTW, the bug label "Reproducible" conflicts with this.
,
Oct 28 2016
Issue 659495 has been merged into this issue.
,
Oct 31 2016
[I tried to repro this and issue 659495 but couldn't; clusterfuzz page is very unfriendly and I didn't figure out how to reporduce.] According to the stack, this appears like CompositorProxy making a lookup for elementId of value zero, which is invalid (this should not happen, because it is invalid as a key of a HashMap). Reassigning to (hopefully) someone more knowledgable in this area. majidvp: Please
,
Oct 31 2016
Oops, hit the submit button a bit too early. majidvp: Can you take a look at this?
,
Nov 7 2016
Tanin, would you mind to do a brief interview of yutak@ to learn what made him unhappy about ClusterFuzz (see c#7). yutak@, we are working on new UI, any feedback would be much appreciated!
,
Nov 7 2016
Regarding c#5, when the crash has been found, it has been also verified and marked as reproducible (== it was reproducible at that moment). This is why we have label:Reproducible here. Then, after some time: [2016-10-26 00:29:34] clusterfuzz-linux-0222: Progression task started: r427507. [2016-10-26 00:31:51] clusterfuzz-linux-0222: Progression task in-progress: Testing r427323:r427507. [2016-10-26 00:34:03] clusterfuzz-linux-0222: Progression task errored out: Known crash revision 427323 did not crash. [2016-10-26 00:34:03] clusterfuzz-linux-0222: Progression task errored out: Test case appears to be flaky. ClusterFuzz hasn't managed to reproduce the crash again. That's bad, but sometimes that happens. In most of such cases we usually get a new reproducible crash. If we don't have a new reproducer, we usually close the issue. But it depends, sometimes it's possible to understand and fix the problem without a reproducer.
,
Dec 7 2016
ClusterFuzz testcase 5758043410399232 is flaky and no longer reproduces, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ta...@google.com
, Oct 25 2016Owner: tkent@chromium.org
Status: Assigned (was: Untriaged)