Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

=>hubbe as part of ffmpeg roll

This looks like memory corruption and could be potentially serious. As such it should probably not wait until I come back from vacation.

Assigning back to Dale, feel free to reassign to someone else.

Hmm +mmoroz since it does seem like it's failing deep in tcmalloc, but I'd expect any corruption to have been caught earlier.

It's possible the non-instrumented assembly code is the culprit though if there's no wider issue with tcmalloc known at the moment.

That sounds familiar to me... However, I don't see allocator_may_return_null option being enabled. Looking more.

Actually, I can't find any similar bug. Maybe it's just OOM reporting in a weird way?

Will investigate. Would be interesting to me if this is OOM reporting as I've seen crashes in this tcmalloc code in the wild forever and always attributed them to memory corruption and not oom.

Hmm, this is just another instance of  issue 849062  but clusterfuzz isn't getting a good stack for some reason. After disabling frame pointer omission I got a good one:

==120177==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6090000052d0 at pc 0x000000445358 bp 0x7f79b498f4f0 sp 0x7f79b498eca0
WRITE of size 136 at 0x6090000052d0 thread T4 (TaskSchedulerFo)
    #0 0x445357 in __asan_memcpy /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23:3
    #1 0x7f79c69be046 in avio_read third_party/ffmpeg/libavformat/aviobuf.c:684:13
    #2 0x7f79c6a2b5eb in mov_read_sample_encryption_info third_party/ffmpeg/libavformat/mov.c:5880:13
    #3 0x7f79c6a2bf47 in mov_parse_auxiliary_info third_party/ffmpeg/libavformat/mov.c:6009:15
    #4 0x7f79c6a26139 in mov_read_saio third_party/ffmpeg/libavformat/mov.c:6224:16
    #5 0x7f79c69f90c4 in mov_read_default third_party/ffmpeg/libavformat/mov.c:6704:23
    #6 0x7f79c69f90c4 in mov_read_default third_party/ffmpeg/libavformat/mov.c:6704:23
    #7 0x7f79c69f90c4 in mov_read_default third_party/ffmpeg/libavformat/mov.c:6704:23
    #8 0x7f79c6a2d142 in mov_switch_root third_party/ffmpeg/libavformat/mov.c:7486:11
    #9 0x7f79c69ff05b in mov_read_packet third_party/ffmpeg/libavformat/mov.c:7533:20
    #10 0x7f79c697f6e7 in ff_read_packet third_party/ffmpeg/libavformat/utils.c:856:15
    #11 0x7f79c698566e in read_frame_internal third_party/ffmpeg/libavformat/utils.c:1581:15
    #12 0x7f79c69942ff in avformat_find_stream_info third_party/ffmpeg/libavformat/utils.c:3773:15


modmaker@ fixed this upstream with https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/4aba45ca1fece6be425d168c05aa3a7f9f05da36

I'm not sure why this didn't make it into the fixes for  issue 849062 . +liberato who handled the merges there. Frank, did the right stuff get merged? Or was this a second patch that wasn't included earlier? I can't really tell from that bug what got merged. The commits you linked don't map to real git hashes.

https://chromium-review.googlesource.com/c/chromium/src/+/1111267 for ToT
https://chromium-review.googlesource.com/c/chromium/src/+/1111276 for M68

Re c#9, wow, nice! You guys were right about the corruption that could've been caught earlier. This crash has been reported by UBSan, which doesn't catch heap-buffer-overflow bugs, that is why we have crashed somewhere after the overflow.

I guess there isn't much we can do from the CF perspective do group such duplicates, when the stacktraces and crash types are significantly different.

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

commit 9ad1fd0056fb613af07967bf9c6b825e1e21cc67
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Jun 22 01:55:54 2018

Roll src/third_party/ffmpeg/ c3b8d611c..de23348fe (2 commits)

https://chromium.googlesource.com/chromium/third_party/ffmpeg.git/+log/c3b8d611c12f..de23348fef6f

$ git log c3b8d611c..de23348fe --date=short --no-merges --format='%ad %ae %s'
2018-06-21 dalecurtis Update patches file for cherry-pick from upstream.
2018-06-12 modmaker-at-google.com avformat/mov: Add check for per-sample IV size.

Created with:
  roll-dep src/third_party/ffmpeg

BUG= 853416 
TBR=liberato

Change-Id: I8794e0e7151258f0ad7d599803a0aeb90efa2917
Reviewed-on: https://chromium-review.googlesource.com/1111267
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569504}
[modify] https://crrev.com/9ad1fd0056fb613af07967bf9c6b825e1e21cc67/DEPS

ClusterFuzz has detected this issue as fixed in range 569503:569504.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_ubsan_vptr_chrome
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  do_memalign
  tc_memalign
  av_mallocz
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_chrome&range=560370:560378
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_chrome&range=569503:569504

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

See https://github.com/google/clusterfuzz-tools 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 4989652994621440 is verified as fixed, so closing issue as verified.

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

[Auto-generated comment by a script] We noticed that this issue is targeted for M-68; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-68 label, otherwise remove Merge-TBD label. Thanks.

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

commit 0d0c062e8cefdfdc777cd36ab23a2b4ddac65fcd
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Fri Jun 22 16:57:36 2018

Update ffmpeg DEPs for rest of iv size fixes.

BUG= 849062 , 853416 

Change-Id: Ida5bff50f4095dadd9314c49c836ec6b80101a4b
Reviewed-on: https://chromium-review.googlesource.com/1111276
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#490}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/0d0c062e8cefdfdc777cd36ab23a2b4ddac65fcd/DEPS

Please request Merge-Request prior to merging. 

This was already approved for merging in  issue 849062 ; that merge was just incomplete.