CHECK failure: buffers_.empty() || CanAppendBuffersToEnd(new_buffers, new_buffers_group_start_p |
||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5327122318229504 Fuzzer: libFuzzer_mediasource_MP4_FLAC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: buffers_.empty() || CanAppendBuffersToEnd(new_buffers, new_buffers_group_start_p media::SourceBufferRangeByPts::AppendBuffersToEnd media::SourceBufferStream<media::SourceBufferRangeByPts>::Append Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=506125:506169 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5327122318229504 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.
,
Oct 4 2017
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Oct 4 2017
Test Predator has given the following results: MSE: Buffer media by PTS when kMseBufferByPts feature is enabled by wolenetz@chromium.org Changelist touched lines near the crashed line in frame #2 media::SourceBufferRangeByPts::AppendBuffersToEnd(base::circular_deque<scoped_refptr<media::StreamParserBuffer> > const&, base::TimeDelta) (distance = 0 lines away) Top touched frame is #2 media::SourceBufferRangeByPts::AppendBuffersToEnd(in source_buffer_range_by_pts.cc) Changed files chunk_demuxer.cc, chunk_demuxer.h, frame_processor.cc, frame_processor.h, frame_processor_unittest.cc, source_buffer_range.cc, source_buffer_range.h, source_buffer_range_by_dts.cc, source_buffer_range_by_dts.h, source_buffer_range_by_pts.cc, source_buffer_range_by_pts.h, source_buffer_stream.cc, source_buffer_stream.h, source_buffer_stream_unittest.cc, with the same CrashedDirectory(media/filters) as source_buffer_range_by_pts.cc (in frame#2) Touched files in stacktrace - source_buffer_range_by_pts.cc Changed files chunk_demuxer.cc, chunk_demuxer.h, frame_processor.cc, frame_processor.h, frame_processor_unittest.cc, source_buffer_range.cc, source_buffer_range.h, source_buffer_range_by_dts.cc, source_buffer_range_by_dts.h, source_buffer_range_by_pts.cc, source_buffer_range_by_pts.h, source_buffer_stream.cc, source_buffer_stream.h, source_buffer_stream_unittest.cc, pipeline_integration_test.cc, with the same CrashedComponent(Internals>Media) as source_buffer_range_by_pts.cc (in frame#2) @wolenetz -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes. Thank You.
,
Oct 9 2017
Similar root cause as bug 771482 (out-of-order keyframe PTS versus prior keyframe PTS needs to trigger new coded frame group signalling when buffering by PTS).
,
Nov 7 2017
,
Nov 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/469d91812fee7b2db7fd55d55bcb7663784c507d commit 469d91812fee7b2db7fd55d55bcb7663784c507d Author: Matt Wolenetz <wolenetz@chromium.org> Date: Tue Nov 14 03:28:27 2017 MSE: If timestampOffset change jumps far enough forward, introduce gap When buffering by either PTS or DTS, and in segments AppendMode, if the web app sets timestampOffset such that the next coded frame for a track emitted from the coded frame processing algorithm is far enough in the future, a buffered range gap can be introduced. This change makes similar behavior occur when in sequence AppendMode. Prior to this change, the intent of sequence mode was assumed to be to not introduce such gaps when jumping forwards due to a newly set timestampOffset. However, such behavior is neither explicit nor required in the MSE spec, and implementing it, especially when buffering compliantly ByPts, is complex and unintuitive. For example, should previously buffered frames in the "gap" be removed? Worse, the previous implementation used an implicit expansion of our buffering adjacency "fudge room" to coalesce such a gap in sequence mode when buffering by DTS, using inter-frame DTS deltas. The net of this change also fixes one source of SBRByPts range adjacency CHECK failures. Subsequent changes will address other sources of related failures in the referenced bugs, below. BUG= 771482 , 771480 , 771473 , 771481 , 771539 , 781766 , 775967 TEST=Updated FrameProcessorTests and added LargeTimestampOffsetJumpForward Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: Iecc30c6ef6bf5c3f7433152cc62793806ecbd653 Reviewed-on: https://chromium-review.googlesource.com/757756 Reviewed-by: Dan Sanders <sandersd@chromium.org> Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org> Cr-Commit-Position: refs/heads/master@{#516169} [modify] https://crrev.com/469d91812fee7b2db7fd55d55bcb7663784c507d/media/filters/frame_processor.cc [modify] https://crrev.com/469d91812fee7b2db7fd55d55bcb7663784c507d/media/filters/frame_processor.h [modify] https://crrev.com/469d91812fee7b2db7fd55d55bcb7663784c507d/media/filters/frame_processor_unittest.cc
,
Nov 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d5f07c6849faa9a88e6358eb001de5a75443d791 commit d5f07c6849faa9a88e6358eb001de5a75443d791 Author: Matt Wolenetz <wolenetz@chromium.org> Date: Wed Nov 15 20:43:05 2017 MSE: When buffering ByPts, handle keyframe with PTS < previous keyframe If FrameProcessor doesn't signal SourceBufferStream of a new coded frame group when buffering ByPts and an otherwise continuous (in DTS) frame sequence has keyframe PTS that does not increase, then code faults are hit. Specifically, A) the underlying SourceBufferRangeByPts could have its keyframe map become out of sequence with respect to the buffers it indexes, violating assumptions of its ordering, and B) internal adjacency checks for the new frame with the previous append can fail. This change adds such signalling to FrameProcessor to avoid these faults when keyframe PTS sequence decreases in a CFG when buffering ByPts. Note that "deep" SAP-Type-2 sequences can still trigger (B), tracked by bug 773115 . TEST=New test cases' ProcessFrames calls triggered A or B previously: SegmentsModeNewByPts/FrameProcessorTest.OOOKeyframePts_1/0 (Hit A) SequenceModeNewByPts/FrameProcessorTest.OOOKeyframePts_1/0 (Hit A)* SegmentsModeNewByPts/FrameProcessorTest.OOOKeyframePts_2/0 (Hit B) SequenceModeNewByPts/FrameProcessorTest.OOOKeyframePts_2/0 (Hit B) * - this test also triggered (B) prior to landing prereq CL 469d9181 BUG= 771482 , 771480 , 771473 , 771481 , 771539 , 781766 , 775967 , 773115 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: I80902f3ce1c0a9262459df0a1092d6bb5cbc400f Reviewed-on: https://chromium-review.googlesource.com/728860 Reviewed-by: Dan Sanders <sandersd@chromium.org> Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org> Cr-Commit-Position: refs/heads/master@{#516814} [modify] https://crrev.com/d5f07c6849faa9a88e6358eb001de5a75443d791/media/filters/frame_processor.cc [modify] https://crrev.com/d5f07c6849faa9a88e6358eb001de5a75443d791/media/filters/frame_processor_unittest.cc [modify] https://crrev.com/d5f07c6849faa9a88e6358eb001de5a75443d791/media/filters/source_buffer_range.cc
,
Nov 16 2017
ClusterFuzz has detected this issue as fixed in range 516771:516815. Detailed report: https://clusterfuzz.com/testcase?key=5327122318229504 Fuzzer: libFuzzer_mediasource_MP4_FLAC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: buffers_.empty() || CanAppendBuffersToEnd(new_buffers, new_buffers_group_start_p media::SourceBufferRangeByPts::AppendBuffersToEnd media::SourceBufferStream<media::SourceBufferRangeByPts>::Append Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=506125:506169 Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=516771:516815 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5327122318229504 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.
,
Dec 5 2017
Unduplicating to ensure CF uniquely verifies this one is fixed.
,
Dec 5 2017
ClusterFuzz has detected this issue as fixed in range 516771:516815. Detailed report: https://clusterfuzz.com/testcase?key=5327122318229504 Fuzzer: libFuzzer_mediasource_MP4_FLAC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: buffers_.empty() || CanAppendBuffersToEnd(new_buffers, new_buffers_group_start_p media::SourceBufferRangeByPts::AppendBuffersToEnd media::SourceBufferStream<media::SourceBufferRangeByPts>::Append Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=506125:506169 Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=516771:516815 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5327122318229504 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. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ClusterFuzz
, Oct 4 2017