FFmpeg: posix_memalign/realloc crash in h264/h265 processing
Reported by
tsniatow...@opera.com,
Sep 14 2017
|
||||
Issue descriptionA rare case in ff_h2645_packet_split may end up calling realloc on memory allocated with alignment, which debug tcmalloc detect as a fatal error. The resulting call stack is basically what was reported in https://bugs.chromium.org/p/chromium/issues/detail?id=690184 and this is generaly seems to be an another instance of https://bugs.chromium.org/p/chromium/issues/detail?id=721872 where a different realloc issue was fixed. realloc/memalign mismatch at 0x716353e7440: non-NULL pointers passed to realloc must be obtained from malloc, calloc, or realloc Received signal 11 SEGV_MAPERR 000000000039 #0 0x7f365df225f2 base::debug::StackTrace::StackTrace() #1 0x7f365df20649 base::debug::StackTrace::StackTrace() #2 0x7f365df213bd base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7f3661097390 <unknown> #4 0x7f3662036c84 tcmalloc::Abort() #5 0x7f366203be95 LogPrintf() #6 0x7f36620452b7 RAW_LOG() #7 0x7f366326888d realloc #8 0x7f364ad935f8 av_realloc_f #9 0x7f364ad93615 av_reallocp_array #10 0x7f364ace2e87 ff_h2645_extract_rbsp #11 0x7f364ace31ba ff_h2645_packet_split (the issue was easier to reproduce when calling ff_h2645_packet_split directly) See https://bugs.chromium.org/p/chromium/issues/detail?id=690184#c10 for repro steps and attached bit of data that, when fed to ff_h2645_packet_split, makes it realloc aligned memory. The issue does not reproduce if ffmpeg is forced to not use aligned malloc functions.
,
Nov 29 2017
John, did you fix this?
,
Nov 29 2017
,
Nov 29 2017
In issue 721872 I fixed libavformat/mov.c for Chromium to always use realloc() on |extradata|. I also opened a ffmpeg bug (https://trac.ffmpeg.org/ticket/6403) and submitted a patch but the bug was closed "until a real-world test-case exists" ?? Looks like there similar cases in libavcodec/h2645_parse.c that need the same treatment. Basically if realloc() is used on a field, realloc() should be used for it everywhere.
,
Nov 30 2017
For reference, this is the local patch we have to avoid this issue:
diff --git a/third_party/ffmpeg/libavcodec/h2645_parse.c b/third_party/ffmpeg/libavcodec/h2645_parse.c
index b0d9ff66f00..5c052df3428 100644
--- a/third_party/ffmpeg/libavcodec/h2645_parse.c
+++ b/third_party/ffmpeg/libavcodec/h2645_parse.c
@@ -318,7 +318,13 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t *buf, int length,
nal = &pkt->nals[pkt->nb_nals];
nal->skipped_bytes_pos_size = 1024; // initial buffer size
+#if 0 // Always use av_reallocp_array() for |skipped_bytes_pos|
nal->skipped_bytes_pos = av_malloc_array(nal->skipped_bytes_pos_size, sizeof(*nal->skipped_bytes_pos));
+#else
+ av_reallocp_array(&nal->skipped_bytes_pos,
+ nal->skipped_bytes_pos_size,
+ sizeof(*nal->skipped_bytes_pos));
+#endif
if (!nal->skipped_bytes_pos)
return AVERROR(ENOMEM);
,
Mar 1 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by dalecur...@chromium.org
, Sep 14 2017Owner: chcunningham@chromium.org
Status: Assigned (was: Untriaged)