GNOME Bugzilla – Bug 673485
[h264parse] Crash in h264parse on a FLV sample
Last modified: 2012-04-06 12:56:11 UTC
Created attachment 211266 [details] Crash repro case Simple gst-launch pipeline crashes in the h264 parser. Not tested on 0.11. See attached first 32 KB of the sample, which is enough to repro. valgrind gst-launch-0.10 filesrc location=/tmp/crash-h264.flv ! flvdemux ! h264parse ! fakesink ==3986== Memcheck, a memory error detector ==3986== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==3986== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==3986== Command: gst-launch-0.10 filesrc location=/tmp/crash-h264.flv ! flvdemux ! h264parse ! fakesink ==3986== GStreamer has detected that it is running inside valgrind. It might now take different code paths to ease debugging. Of course, this may also lead to different bugs. Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ==3986== Thread 2: ==3986== Invalid write of size 1 ==3986== at 0x4C29910: memcpy (mc_replace_strmem.c:497) ==3986== by 0x89DE114: gst_byte_writer_put_data_unchecked (gstbytewriter.h:260) ==3986== by 0x89E3661: gst_h264_parse_pre_push_frame (gsth264parse.c:1517) ==3986== by 0x834BE27: gst_base_parse_push_frame (gstbaseparse.c:1915) ==3986== by 0x83505FD: gst_base_parse_handle_and_push_frame (gstbaseparse.c:1773) ==3986== by 0x83516AC: gst_base_parse_chain (gstbaseparse.c:2466) ==3986== by 0x89E495B: gst_h264_parse_chain (gsth264parse.c:1889) ==3986== by 0x4E85C78: gst_pad_chain_data_unchecked (gstpad.c:4271) ==3986== by 0x4E8657C: gst_pad_push_data (gstpad.c:4506) ==3986== by 0x4E8D8F2: gst_pad_push (gstpad.c:4730) ==3986== by 0x859BE96: gst_flv_demux_parse_tag_video (gstflvdemux.c:1425) ==3986== by 0x859DE40: gst_flv_demux_pull_tag (gstflvdemux.c:2050) ==3986== Address 0x7eefa84 is not stack'd, malloc'd or (recently) free'd ==3986== ==3986== Invalid write of size 1 ==3986== at 0x4C2991A: memcpy (mc_replace_strmem.c:497) ==3986== by 0x89DE114: gst_byte_writer_put_data_unchecked (gstbytewriter.h:260) ==3986== by 0x89E3661: gst_h264_parse_pre_push_frame (gsth264parse.c:1517) ==3986== by 0x834BE27: gst_base_parse_push_frame (gstbaseparse.c:1915) ==3986== by 0x83505FD: gst_base_parse_handle_and_push_frame (gstbaseparse.c:1773) ==3986== by 0x83516AC: gst_base_parse_chain (gstbaseparse.c:2466) ==3986== by 0x89E495B: gst_h264_parse_chain (gsth264parse.c:1889) ==3986== by 0x4E85C78: gst_pad_chain_data_unchecked (gstpad.c:4271) ==3986== by 0x4E8657C: gst_pad_push_data (gstpad.c:4506) ==3986== by 0x4E8D8F2: gst_pad_push (gstpad.c:4730) ==3986== by 0x859BE96: gst_flv_demux_parse_tag_video (gstflvdemux.c:1425) ==3986== by 0x859DE40: gst_flv_demux_pull_tag (gstflvdemux.c:2050) ==3986== Address 0x7eefa83 is not stack'd, malloc'd or (recently) free'd ==3986== [...] See attached first 32 KB of the sample, which is enough to repro.
Crashes with 0.11 too: ==2924== Thread 2: ==2924== Invalid write of size 1 ==2924== at 0x402B845: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2924== by 0x4A57358: gst_buffer_extract (gstbuffer.c:1318) ==2924== by 0x853DCE4: gst_h264_parse_pre_push_frame (gstbytewriter.h:316) ==2924== by 0x7408C47: gst_base_parse_push_frame (gstbaseparse.c:2037) ==2924== by 0x740BD7A: gst_base_parse_finish_frame (gstbaseparse.c:1915) ==2924== by 0x853F904: gst_h264_parse_handle_frame (gsth264parse.c:693) ==2924== by 0x7406B02: gst_base_parse_handle_buffer (gstbaseparse.c:1774) ==2924== by 0x7409983: gst_base_parse_chain (gstbaseparse.c:2603) ==2924== by 0x4A7E0D7: gst_pad_push_data (gstpad.c:3501) ==2924== by 0x764C926: gst_flv_demux_parse_tag_video (gstflvdemux.c:1459) ==2924== by 0x764FE4C: gst_flv_demux_loop (gstflvdemux.c:2090) ==2924== by 0x4AAC208: gst_task_func (gsttask.c:316) ==2924== Address 0x70c0184 is not stack'd, malloc'd or (recently) free'd
Fixed in 0.10 (and also merged into 1.0): commit 0882adc69f7a3e420c56f5ba8c4cabb942e285b8 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Fri Apr 6 14:23:53 2012 +0200 h264parse: do not use _unchecked bytewriter variants to insert config .. since the bytewriter is explicitly created with non-fixed size to allow (very much so expected) growth. Partially reverts commit 20669d461a4953eb5ed01374d5ab628b4dc73b64 while trying to keep (some?) compilers happy. IIRC, the purpose of GstByteWriter in the first place was (at least) being able to dump data without having to fuss with memory expansion and size issues ... Fixes #673485.