Null-dereference READ in media::DecoderBuffer::timestamp |
||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4528161898627072 Fuzzer: libFuzzer_mediasource_MP4_AACLC_AVC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000000 Crash State: media::DecoderBuffer::timestamp media::SourceBufferRange::UpdateEndTime media::SourceBufferRangeByPts::UpdateEndTimeUsingLastGOP Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=506125:506169 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4528161898627072 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.
,
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 #5 media::SourceBufferStream<media::SourceBufferRangeByPts>::RemoveInternal(media::DecodeTimestamp, media::DecodeTimestamp, bool, base::circular_deque<scoped_refptr<media::StreamParserBuffer> >*) (distance = 0 lines away) Top touched frame is #1 media::SourceBufferRange::UpdateEndTime(in source_buffer_range.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_stream.cc (in frame#4, frame#5, frame#6), source_buffer_range_by_pts.cc (in frame#2, frame#3), source_buffer_range.cc (in frame#1) Touched files in stacktrace - source_buffer_range_by_pts.cc, source_buffer_range.cc, source_buffer_stream.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_stream.cc (in frame#4, frame#5, frame#6), source_buffer_range_by_pts.cc (in frame#2, frame#3), decoder_buffer.h (in frame#0), source_buffer_range.cc (in frame#1) @wolenetz -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes. Thank You.
,
Oct 4 2017
,
Oct 9 2017
Same root cause as bug 771482 . I'm working on a fix associated with bug 771482 .
,
Oct 9 2017
,
Nov 1 2017
ClusterFuzz has detected this issue as fixed in range 512995:513017. Detailed report: https://clusterfuzz.com/testcase?key=4528161898627072 Fuzzer: libFuzzer_mediasource_MP4_AACLC_AVC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000000 Crash State: media::DecoderBuffer::timestamp media::SourceBufferRange::UpdateEndTime media::SourceBufferRangeByPts::UpdateEndTimeUsingLastGOP 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=512995:513017 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4528161898627072 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.
,
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 14 2017
I'm now unable to reproduce this issue; underlying parser change https://chromium-review.googlesource.com/747080 avoids the code fault (that still exists, leading to out-of-order keyframe_map_ in SBRByPts, like bug 771482 and related). I'll continue working on those fixes. I confirmed that reverting https://chromium-review.googlesource.com/747080 allows repro locally of the CF issue, so I can still use the repro case (with that temporary revert) for deeper verification of the fix for this group of related issues.
,
Nov 14 2017
ClusterFuzz has detected this issue as fixed in range 512995:513017. Detailed report: https://clusterfuzz.com/testcase?key=4528161898627072 Fuzzer: libFuzzer_mediasource_MP4_AACLC_AVC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000000 Crash State: media::DecoderBuffer::timestamp media::SourceBufferRange::UpdateEndTime media::SourceBufferRangeByPts::UpdateEndTimeUsingLastGOP 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=512995:513017 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4528161898627072 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.
,
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 21 2017
It looks like #11 has fixed the underlying issue of this particular bug. I can no longer repro this with https://chromium-review.googlesource.com/747080 reverted (versus #9, earlier).
,
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 512995:513017. Detailed report: https://clusterfuzz.com/testcase?key=4528161898627072 Fuzzer: libFuzzer_mediasource_MP4_AACLC_AVC_pipeline_integration_fuzzer Job Type: libfuzzer_chrome_asan Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000000 Crash State: media::DecoderBuffer::timestamp media::SourceBufferRange::UpdateEndTime media::SourceBufferRangeByPts::UpdateEndTimeUsingLastGOP 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=512995:513017 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4528161898627072 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 2017Labels: Test-Predator-AutoComponents