GNOME Bugzilla – Bug 722467
pad: Leaks events when iterating sticky events and callback drops event
Last modified: 2014-01-18 09:35:58 UTC
To reproduce: ffmpeg -loglevel fatal -t 10 -f lavfi -i testsrc -f mpegts - | G_SLICE=always-malloc valgrind --suppressions=valgrind.supp --show-reachable=no gst-launch-1.0 filesrc location=/dev/stdin ! tsdemux ! decodebin ! fakesink ==13884== Memcheck, a memory error detector ==13884== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==13884== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==13884== Command: gst-launch-1.0 filesrc location=/dev/stdin ! tsdemux ! decodebin ! fakesink ==13884== 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 ... Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:01.531771960 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... ==13884== ==13884== HEAP SUMMARY: ==13884== in use at exit: 464,269 bytes in 2,456 blocks ==13884== total heap usage: 50,463 allocs, 48,007 frees, 8,584,867 bytes allocated ==13884== ==13884== 370 (32 direct, 338 indirect) bytes in 1 blocks are definitely lost in loss record 2,245 of 2,297 ==13884== at 0x4C2C5DB: malloc (vg_replace_malloc.c:270) ==13884== by 0x591221A: g_malloc (gmem.c:159) ==13884== by 0x592AC50: g_slice_alloc (gslice.c:1003) ==13884== by 0x4ED542F: gst_structure_new_id_empty_with_size (gststructure.c:147) ==13884== by 0x4ED551A: gst_structure_new_id_empty (gststructure.c:174) ==13884== by 0x4ED6FA2: gst_structure_new_id (gststructure.c:757) ==13884== by 0x4E96FEC: gst_event_new_stream_start (gstevent.c:1405) ==13884== by 0x74C812E: create_pad_for_stream (tsdemux.c:1072) ==13884== by 0x74C8289: gst_ts_demux_stream_added (tsdemux.c:1106) ==13884== by 0x74BE69B: mpegts_base_program_add_stream (mpegtsbase.c:481) ==13884== by 0x74BF501: mpegts_base_activate_program (mpegtsbase.c:706) ==13884== by 0x74BFED7: mpegts_base_apply_pmt (mpegtsbase.c:882) ==13884== by 0x74C00ED: mpegts_base_handle_psi (mpegtsbase.c:919) ==13884== by 0x74C0A54: mpegts_base_chain (mpegtsbase.c:1134) ==13884== by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773) ==13884== by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006) ==13884== by 0x4EB2488: gst_pad_push (gstpad.c:4109) ==13884== by 0x727904F: gst_base_src_loop (gstbasesrc.c:2785) ==13884== by 0x4EE6047: gst_task_func (gsttask.c:316) ==13884== by 0x4EE7142: default_func (gsttaskpool.c:70) ==13884== by 0x59379BD: g_thread_pool_thread_proxy (gthreadpool.c:309) ==13884== by 0x59373D2: g_thread_proxy (gthread.c:798) ==13884== by 0x601BDA5: start_thread (in /lib64/libpthread-2.15.so) ==13884== ==13884== 464 (32 direct, 432 indirect) bytes in 1 blocks are definitely lost in loss record 2,249 of 2,297 ==13884== at 0x4C2C5DB: malloc (vg_replace_malloc.c:270) ==13884== by 0x591221A: g_malloc (gmem.c:159) ==13884== by 0x592AC50: g_slice_alloc (gslice.c:1003) ==13884== by 0x4ED542F: gst_structure_new_id_empty_with_size (gststructure.c:147) ==13884== by 0x4ED551A: gst_structure_new_id_empty (gststructure.c:174) ==13884== by 0x4ED6FA2: gst_structure_new_id (gststructure.c:757) ==13884== by 0x4E953A1: gst_event_new_caps (gstevent.c:630) ==13884== by 0x7023194: gst_pad_set_caps (gstcompat.h:52) ==13884== by 0x70233EC: gst_type_find_element_have_type (gsttypefindelement.c:190) ==13884== by 0x65E1F1B: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.0) ==13884== by 0x65E18B3: ffi_call (in /usr/lib64/libffi.so.6.0.0) ==13884== by 0x546B008: g_cclosure_marshal_generic (gclosure.c:1454) ==13884== by 0x5469F20: g_type_class_meta_marshal (gclosure.c:970) ==13884== by 0x546986B: g_closure_invoke (gclosure.c:777) ==13884== by 0x5487157: signal_emit_unlocked_R (gsignal.c:3514) ==13884== by 0x54866AA: g_signal_emit_valist (gsignal.c:3328) ==13884== by 0x5486BF3: g_signal_emit (gsignal.c:3384) ==13884== by 0x70250BC: gst_type_find_element_setcaps (gsttypefindelement.c:715) ==13884== by 0x7024CAE: gst_type_find_element_sink_event (gsttypefindelement.c:618) ==13884== by 0x4EB4F2B: gst_pad_send_event_unchecked (gstpad.c:5051) ==13884== by 0x4EB416E: gst_pad_push_event_unchecked (gstpad.c:4747) ==13884== by 0x4EAF9A4: push_sticky (gstpad.c:3380) ==13884== by 0x4EA75F4: events_foreach (gstpad.c:533) ==13884== by 0x4EAFD2E: check_sticky (gstpad.c:3436) ==13884== by 0x4EB4609: gst_pad_push_event (gstpad.c:4864) ==13884== by 0x4EAE11D: event_forward_func (gstpad.c:2777) ==13884== by 0x4EADF16: gst_pad_forward (gstpad.c:2731) ==13884== by 0x4EAE2CF: gst_pad_event_default (gstpad.c:2828) ==13884== by 0x4EB4F2B: gst_pad_send_event_unchecked (gstpad.c:5051) ==13884== by 0x4EB416E: gst_pad_push_event_unchecked (gstpad.c:4747) ==13884== by 0x4EAF9A4: push_sticky (gstpad.c:3380) ==13884== by 0x4EA75F4: events_foreach (gstpad.c:533) ==13884== by 0x4EAFD2E: check_sticky (gstpad.c:3436) ==13884== by 0x4EB4609: gst_pad_push_event (gstpad.c:4864) ==13884== by 0x74CB874: calculate_and_push_newsegment (tsdemux.c:1666) ==13884== by 0x74CBCCD: gst_ts_demux_push_pending_data (tsdemux.c:1731) ==13884== by 0x74CC9E1: gst_ts_demux_handle_packet (tsdemux.c:1802) ==13884== by 0x74CCB02: gst_ts_demux_push (tsdemux.c:1840) ==13884== by 0x74C09C0: mpegts_base_chain (mpegtsbase.c:1125) ==13884== by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773) ==13884== by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006) ==13884== by 0x4EB2488: gst_pad_push (gstpad.c:4109) ==13884== by 0x727904F: gst_base_src_loop (gstbasesrc.c:2785) ==13884== by 0x4EE6047: gst_task_func (gsttask.c:316) ==13884== by 0x4EE7142: default_func (gsttaskpool.c:70) ==13884== by 0x59379BD: g_thread_pool_thread_proxy (gthreadpool.c:309) ==13884== by 0x59373D2: g_thread_proxy (gthread.c:798) ==13884== by 0x601BDA5: start_thread (in /lib64/libpthread-2.15.so) ==13884== ==13884== 1,379 (32 direct, 1,347 indirect) bytes in 1 blocks are definitely lost in loss record 2,273 of 2,297 ==13884== at 0x4C2C5DB: malloc (vg_replace_malloc.c:270) ==13884== by 0x591221A: g_malloc (gmem.c:159) ==13884== by 0x592AC50: g_slice_alloc (gslice.c:1003) ==13884== by 0x4ED542F: gst_structure_new_id_empty_with_size (gststructure.c:147) ==13884== by 0x4ED551A: gst_structure_new_id_empty (gststructure.c:174) ==13884== by 0x4ED6FA2: gst_structure_new_id (gststructure.c:757) ==13884== by 0x4E953A1: gst_event_new_caps (gstevent.c:630) ==13884== by 0x992F91C: gst_pad_set_caps (gstcompat.h:52) ==13884== by 0x99321D1: gst_mpegv_parse_update_src_caps (gstmpegvideoparse.c:886) ==13884== by 0x99323DC: gst_mpegv_parse_parse_frame (gstmpegvideoparse.c:926) ==13884== by 0x993185A: gst_mpegv_parse_handle_frame (gstmpegvideoparse.c:700) ==13884== by 0x72519A7: gst_base_parse_handle_buffer (gstbaseparse.c:1959) ==13884== by 0x72564F3: gst_base_parse_chain (gstbaseparse.c:2880) ==13884== by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773) ==13884== by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006) ==13884== by 0x4EB2488: gst_pad_push (gstpad.c:4109) ==13884== by 0x7025544: gst_type_find_element_chain (gsttypefindelement.c:826) ==13884== by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773) ==13884== by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006) ==13884== by 0x4EB2488: gst_pad_push (gstpad.c:4109) ==13884== by 0x4E98087: gst_proxy_pad_chain_default (gstghostpad.c:128) ==13884== by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773) ==13884== by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006) ==13884== by 0x4EB2488: gst_pad_push (gstpad.c:4109) ==13884== by 0x74CC64E: gst_ts_demux_push_pending_data (tsdemux.c:1763) ==13884== by 0x74CC9E1: gst_ts_demux_handle_packet (tsdemux.c:1802) ==13884== by 0x74CCB02: gst_ts_demux_push (tsdemux.c:1840) ==13884== by 0x74C09C0: mpegts_base_chain (mpegtsbase.c:1125) ==13884== by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773) ==13884== by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006) ==13884== by 0x4EB2488: gst_pad_push (gstpad.c:4109) ==13884== by 0x727904F: gst_base_src_loop (gstbasesrc.c:2785) ==13884== by 0x4EE6047: gst_task_func (gsttask.c:316) ==13884== by 0x4EE7142: default_func (gsttaskpool.c:70) ==13884== by 0x59379BD: g_thread_pool_thread_proxy (gthreadpool.c:309) ==13884== by 0x59373D2: g_thread_proxy (gthread.c:798) ==13884== by 0x601BDA5: start_thread (in /lib64/libpthread-2.15.so) ==13884== ==13884== LEAK SUMMARY: ==13884== definitely lost: 96 bytes in 3 blocks ==13884== indirectly lost: 2,117 bytes in 27 blocks ==13884== possibly lost: 0 bytes in 0 blocks ==13884== still reachable: 37,985 bytes in 643 blocks ==13884== suppressed: 424,071 bytes in 1,783 blocks ==13884== Reachable blocks (those to which a pointer was found) are not shown. ==13884== To see them, rerun with: --leak-check=full --show-reachable=yes ==13884== ==13884== For counts of detected and suppressed errors, rerun with: -v ==13884== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 175 from 175) decodebin dot diagram shows that in this case it consists of typefind, mpegvideoparse and mpeg2dec. Substituting decodebin with a simple bin with these elements doesn't reproduce the problem: ffmpeg -loglevel fatal -t 10 -f lavfi -i testsrc -f mpegts - | G_SLICE=always-malloc valgrind --suppressions=valgrind.supp --show-reachable=no gst-launch-1.0 filesrc location=/dev/stdin ! tsdemux ! bin. \( typefind ! mpegvideoparse ! mpeg2dec \) ! fakesink ==14063== Memcheck, a memory error detector ==14063== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==14063== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==14063== Command: gst-launch-1.0 filesrc location=/dev/stdin ! tsdemux ! bin. ( typefind ! mpegvideoparse ! mpeg2dec ) ! fakesink ==14063== 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 ... Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:01.585542681 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... ==14063== ==14063== HEAP SUMMARY: ==14063== in use at exit: 417,605 bytes in 2,233 blocks ==14063== total heap usage: 45,860 allocs, 43,627 frees, 8,350,308 bytes allocated ==14063== ==14063== LEAK SUMMARY: ==14063== definitely lost: 0 bytes in 0 blocks ==14063== indirectly lost: 0 bytes in 0 blocks ==14063== possibly lost: 0 bytes in 0 blocks ==14063== still reachable: 31,978 bytes in 599 blocks ==14063== suppressed: 385,627 bytes in 1,634 blocks ==14063== Reachable blocks (those to which a pointer was found) are not shown. ==14063== To see them, rerun with: --leak-check=full --show-reachable=yes ==14063== ==14063== For counts of detected and suppressed errors, rerun with: -v ==14063== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 153 from 153)
Fixed on master Module: gstreamer Branch: master Commit: 75fe1004a52435afbe5abf68c1128ec5db62c3d6 URL: http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=75fe1004a52435afbe5abf68c1128ec5db62c3d6 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Fri Jan 17 22:53:01 2014 -0300 pad: fix sticky event leak after sticky_events_foreach events_foreach adds an extra ref when giving the event to the user function. In case it was unrefed by the user, this extra ref disappeared, but events_foreach still should unref again to lose its own ref before removing the event from the array. https://bugzilla.gnome.org/show_bug.cgi?id=722467
Also pushed to 1.2 commit c6f8d255574229fc3f7584f8ad37adbe4c484637 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Fri Jan 17 22:53:01 2014 -0300 pad: fix sticky event leak after sticky_events_foreach events_foreach adds an extra ref when giving the event to the user function. In case it was unrefed by the user, this extra ref disappeared, but events_foreach still should unref again to lose its own ref before removing the event from the array. https://bugzilla.gnome.org/show_bug.cgi?id=722467
Thanks for fixing.