Timeout in mediasource_MP4_AVC1_pipeline_integration_fuzzer |
||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5833128336424960 Fuzzer: libFuzzer_mediasource_MP4_AVC1_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: mediasource_MP4_AVC1_pipeline_integration_fuzzer Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=497006:497252 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5833128336424960 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
,
Nov 17
Automatically adding ccs based on OWNERS file / target commit history. If this is incorrect, please add ClusterFuzz-Wrong label.
,
Nov 20
,
Nov 20
,
Nov 20
load balancing to ted, probably another too many atoms that isn't fixable.
,
Nov 20
Ted, if this is another case of huge trun sample_count, all with sample_size 0, please mark this issue as blocked on bug 907268.
,
Nov 21
,
Dec 1
ClusterFuzz testcase 5833128336424960 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.
,
Dec 6
,
Dec 7
Turns out this is a problem with encrypted stream flags: MediaSourcePipelineIntegrationFuzzerTest::RunTest Starts the pipeline with a null FakeEncryptedMedia pointer, which means that the pipeline never sets cdm_context_ in the RendererImpl. However, one of the streams in the CF testcase has a bit marked as encrypted, so the "HasEncryptedStream() && !cdm_context_" condition causing RendererImpl::Initialize to exit early, which means that init_cb_ never gets called, and the pipeline blocks forever.
,
Dec 7
Interesting, should we inject some sort of fake cdm?
,
Dec 7
Given the async nature of our media pipeline, there'll always be fuzz cases where the media pipeline will sit there waiting and then time out. I feel we should have a way to mark these timeout as expected, instead of trying to "fix" them. For example, in this case, if we provide a fake CDM, the code will execute a different path then we actually lose some code coverage...
,
Dec 7
I wouldn't call it losing coverage :) Anything that lets the fuzzer progress further on this content would be useful, but if you don't think that's helpful here we can close as wontfix.
,
Dec 7
I think this TODO covers this exact case: https://cs.chromium.org/chromium/src/media/test/pipeline_integration_fuzzertest.cc?l=130 |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ClusterFuzz
, Nov 17