Timeout in mediasource_MP4_FLAC_pipeline_integration_fuzzer |
||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6637172018118656 Fuzzer: libFuzzer_mediasource_MP4_FLAC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: mediasource_MP4_FLAC_pipeline_integration_fuzzer Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6637172018118656 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.
,
Sep 8 2017
Redo Task has been performed for regression range. Thank You.
,
Sep 8 2017
Note, while there is a large trun.sample_count, it's not large enough to trigger the OOM in bug 759277, so not a duplicate of that. The fuzzer is attempting decode when it times out. In a local repro, the parser emits tiny frames, they're sent to be decoded. OnDecodeDone occurs for the first few dozen frames, but eventually no further OnDecodeDone. perf profiler confirmed that majority of fuzzer time is being spent in ffmpeg. Considering this is could be ffmpeg problem, I tried and *confirmed repro* using SRC= fuzzer (media_pipeline_integration_fuzzer) for this fuzzer case. But upstream ffplay as of May 6 2017 8ef2c791c99e7c103782e889e2bca2f6e13a07be does *not* repro stalled decode progress (for at least the first few thousand decodes). Neither does current upstream ffplay 260ea7a7b395891b12eeddbd9042e0a4d3c72db9 (I'd expect the SRC=fuzzer still to timeout even if decodes proceed, because there are ~197k buffers emitted from the parser, but the decodes stall even for that fuzzer). I also tried just SRC= Chrome M61 browser playback of the case (renamed to mp4), and media-internals showed < 100 of debug logs like the following but then progress stalled (repro'ing fuzzer's lack of forward progress *and* lack of signalling decode error to the web app) : Dropping audio frame which failed decode with timestamp: 0 us, duration: 0 us, packet size: 11 bytes ... Dropping audio frame which failed decode with timestamp: 3448163 us, duration: 0 us, packet size: 11 bytes => dalecurtis@ this (stalled decode causing timeout, not media element error) looks like it's some combo of Chrome's use of ffmpeg decode while ffmpegdecode+pipeline path, not specific to MSE.
,
Sep 29 2017
Duration is 05h43m11s per ffmpeg, so I think this is kind of expected. We probably shouldn't ignore based on duration though since that can be a lie. So I think this is WontFix, media stuff is sometimes going to time out and sometimes going to oom. Fuzzer needs to be resilient to these cases and not get stuck.
,
Dec 18 2017
,
Dec 21 2017
Issue 796553 has been merged into this issue. |
||||
►
Sign in to add a comment |
||||
Comment 1 by ClusterFuzz
, Sep 8 2017