I have a local repro. Investigating.

This one is tricky.
It looks like:
1) [a,b) [c,d) is buffered previously
2) A new coded frame group is signaled with time x in [c,d), but x is also within fudge room of the end of [a,b) (I think).

I'll need to investigate further to confirm. If what I think is happening is indeed happening, then a fix would be to attempt to coalesce each range with its range at the end of every append, such that state like (2) cannot occur between appends (because fudge room could have increased over time...)

Deeper analysis of repro logs in a dcheck_always_on build that lead to !IsRangeListSorted() DCHECK failure confirms #5 is at least part of the problem. The fudge room increased after [a,b) and [c,d) were appended previously (an example would be while appending [e,f), then #5.)

Unsorted range lists break basic assumptions, leading to many issues later.

CL: https://chromium-review.googlesource.com/c/chromium/src/+/820656

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5d03c84689520e76673121751641d53314db60a7

commit 5d03c84689520e76673121751641d53314db60a7
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Wed Dec 13 01:05:40 2017

MSE: Try to coalesce buffered ranges when fudge room changes

Before this change, an unsorted sequence of buffered ranges could
result from complex scenarios (in both ByDts and ByPts API usage).
A simple example of such unsorted ranges is [a,b) [c,d), where b > c.

This change prevents one known cause of unsorted ranges: when buffering
a set of frames emitted from FrameProcessor and those frames change the
fudge room, use the new fudge room to try to coalesce any existing
buffered ranges before buffering the new frames. This allows the
buffering code to correctly identify the (at most one) existing buffered
range to which a new buffer or coded frame group start time belongs.
Code already exists to ensure that such fudge room changes are only
increases.

BUG= 793247 
TEST=SourceBufferStreamTest.RangeCoalescenceOnFudgeRoomIncrease_*, and no
more local repro of fuzzer case in crbug 793247

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: If6f78d56080ecb9bbdaef9df554c07f999d9a0ea
Reviewed-on: https://chromium-review.googlesource.com/820656
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523641}
[modify] https://crrev.com/5d03c84689520e76673121751641d53314db60a7/media/filters/source_buffer_stream.cc
[modify] https://crrev.com/5d03c84689520e76673121751641d53314db60a7/media/filters/source_buffer_stream.h
[modify] https://crrev.com/5d03c84689520e76673121751641d53314db60a7/media/filters/source_buffer_stream_unittest.cc

ClusterFuzz has detected this issue as fixed in range 523625:523652.

Detailed report: https://clusterfuzz.com/testcase?key=5678301552312320

Fuzzer: libFuzzer_mediasource_MP4_AACLC_AVC_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Abrt
Crash Address: 0x03e900002fb2
Crash State:
  media::SourceBufferRangeByPts::AppendBuffersToEnd
  media::SourceBufferStream<media::SourceBufferRangeByPts>::Append
  media::ChunkDemuxerStream::Append
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=518239:518261
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=523625:523652

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5678301552312320

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.

ClusterFuzz testcase 5678301552312320 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.