GNOME Bugzilla – Bug 747110
aacdec: Invalid read reported by valgrind
Last modified: 2018-11-03 12:57:07 UTC
Running this test with valgrind reports invalid reads in libav: gst-validate-launcher -t validate.file.media_check.tron_en_ge_aac_h264_ts -v ==17017== Thread 6 multiqueue0:src_: ==17017== Invalid read of size 4 ==17017== at 0xBAC045C: decode_spectrum_and_dequant (.c:1586) ==17017== by 0xBAC045C: decode_ics.constprop.26 (aacdec.c:1882) ==17017== by 0xBAC15C7: decode_cpe (aacdec.c:1993) ==17017== by 0xBAC2447: aac_decode_frame_int (aacdec.c:2816) ==17017== by 0xBAC3377: aac_decode_frame (aacdec.c:2950) ==17017== by 0xB9D2385: avcodec_decode_audio4 (utils.c:1657) ==17017== by 0xB66716D: gst_ffmpegauddec_audio_frame.isra.0 (gstavauddec.c:475) ==17017== by 0xB6676D1: gst_ffmpegauddec_frame (gstavauddec.c:630) ==17017== by 0xB667F0F: gst_ffmpegauddec_handle_frame (gstavauddec.c:751) ==17017== by 0x50C432D: gst_audio_decoder_push_buffers (gstaudiodecoder.c:1482) ==17017== by 0x50C486A: gst_audio_decoder_chain_forward (gstaudiodecoder.c:1596) ==17017== by 0x50C631B: gst_audio_decoder_chain (gstaudiodecoder.c:1854) ==17017== by 0x5A9223D: gst_pad_chain_data_unchecked (gstpad.c:3977) ==17017== by 0x5A92EEC: gst_pad_push_data (gstpad.c:4210) ==17017== by 0x5A9347B: gst_pad_push (gstpad.c:4321) ==17017== by 0x57B4FA6: gst_base_parse_push_frame (gstbaseparse.c:2332) ==17017== by 0x57B3EEC: gst_base_parse_handle_and_push_frame (gstbaseparse.c:2164) ==17017== by 0x57B587C: gst_base_parse_finish_frame (gstbaseparse.c:2489) ==17017== by 0xABB6B90: gst_aac_parse_handle_frame (gstaacparse.c:1330) ==17017== by 0x57B3163: gst_base_parse_handle_buffer (gstbaseparse.c:1978) ==17017== by 0x57B8231: gst_base_parse_chain (gstbaseparse.c:3018) ==17017== Address 0x62690c7 is 279 bytes inside a block of size 281 alloc'd ==17017== at 0x4A08BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17017== by 0x3EBB04F405: g_malloc (gmem.c:97) ==17017== by 0x8B06C9B: gst_ts_demux_parse_pes_header (tsdemux.c:1830) ==17017== by 0x8B06C9B: gst_ts_demux_queue_data (tsdemux.c:1889) ==17017== by 0x8B06C9B: gst_ts_demux_handle_packet (tsdemux.c:2257) ==17017== by 0x8B06C9B: gst_ts_demux_push (tsdemux.c:2332) ==17017== by 0x8AFFEDF: mpegts_base_chain (mpegtsbase.c:1162) ==17017== by 0x8B00149: mpegts_base_loop (mpegtsbase.c:1341) ==17017== by 0x5AC7894: gst_task_func (gsttask.c:331) ==17017== by 0x5AC8970: default_func (gsttaskpool.c:68) ==17017== by 0x3EBB070D67: g_thread_pool_thread_proxy (gthreadpool.c:307) ==17017== by 0x3EBB0703D4: g_thread_proxy (gthread.c:764) ==17017== by 0x3EB8807529: start_thread (pthread_create.c:310) ==17017== by 0x3EB850022C: clone (clone.S:109)
Created attachment 302139 [details] valgrind logs Here is the full valgrind log when running validate.file.playback.play_15s.tron_en_ge_aac_h264_ts. Playing the same media with avplay doesn't raise those errors so I guess there is something wrong regarding memory management in gst-libav.
Olivier suggested that this may be because libav may expect data to have a specific size and libav's demuxer adds some padding at the end to fit.
*** Bug 752989 has been marked as a duplicate of this bug. ***
i did see this bug.. but for this bug it is showing as "Invalid read of size 4" and for 752989 "Use of uninitialised value of size 4", so i thought it was different. And the cause of both seemed to be different.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/20.