Why this events leak happen?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Why this events leak happen?

Andrey Utkin
I am still not 100% sure this is a GStreamer bug, although partially
very likely.

Trying to simulate the situation in my app, i made up the following
gst-launch command:

GST_DEBUG=3 G_SLICE=always-malloc valgrind --show-reachable=no
--suppressions=gst.supp gst-launch-1.0 udpsrc uri=udp://225.1.1.1:1234
multicast-iface=lo ! tsdemux name=demux demux.video_0100 ! tee name=t
t.src_0 ! h264parse ! avdec_h264 ! fakesink  t.src_1 ! h264parse !
avdec_h264 ! fakesink   t.src_2 ! h264parse ! avdec_h264 ! fakesink
t.src_3 ! h264parse ! avdec_h264 ! fakesink

Input is just MPEG TS with H.264 stream. (I avoided videotestsrc here
because it produces valgrind false positives by itself. But you should
be able to use it with same result, too). The demuxed result is Tee'ed
4 times. In valgrind log, you see below log.

In my real app, i have same
gst_video_decoder_sink_event_default-related leak, and some others
(gst_event_new_caps, gst_event_new_stream_start,
gst_h264_parse_update_src_caps - for them i cannot produce testcase
and can consider a bug in my app).

gst-everything is from today's git master.

Thanks for any help.

==14260== HEAP SUMMARY:
==14260==     in use at exit: 625,643 bytes in 4,825 blocks
==14260==   total heap usage: 85,654 allocs, 80,829 frees, 24,134,262
bytes allocated
==14260==
==14260== 72 bytes in 3 blocks are definitely lost in loss record 1,798 of 2,576
==14260==    at 0x4C2C5DB: malloc (vg_replace_malloc.c:270)
==14260==    by 0x591221A: g_malloc (gmem.c:159)
==14260==    by 0x592AC50: g_slice_alloc (gslice.c:1003)
==14260==    by 0x5905FB2: g_list_prepend (glist.c:279)
==14260==    by 0x84E2491: gst_video_decoder_sink_event_default
(gstvideodecoder.c:1172)
==14260==    by 0x84E2606: gst_video_decoder_sink_event (gstvideodecoder.c:1204)
==14260==    by 0x4EB4F2B: gst_pad_send_event_unchecked (gstpad.c:5051)
==14260==    by 0x4EB416E: gst_pad_push_event_unchecked (gstpad.c:4747)
==14260==    by 0x4EAF9A4: push_sticky (gstpad.c:3380)
==14260==    by 0x4EA75F4: events_foreach (gstpad.c:533)
==14260==    by 0x4EAFD2E: check_sticky (gstpad.c:3436)
==14260==    by 0x4EB4609: gst_pad_push_event (gstpad.c:4864)
==14260==    by 0x720FD73: gst_base_parse_push_pending_events
(gstbaseparse.c:2025)
==14260==    by 0x7210E78: gst_base_parse_push_frame (gstbaseparse.c:2203)
==14260==    by 0x7210608: gst_base_parse_handle_and_push_frame
(gstbaseparse.c:2131)
==14260==    by 0x72120A8: gst_base_parse_finish_frame (gstbaseparse.c:2453)
==14260==    by 0x909F3D4: gst_h264_parse_handle_frame (gsth264parse.c:959)
==14260==    by 0x720F9A7: gst_base_parse_handle_buffer (gstbaseparse.c:1959)
==14260==    by 0x72144F3: gst_base_parse_chain (gstbaseparse.c:2880)
==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
==14260==    by 0x8E78366: gst_tee_do_push (gsttee.c:586)
==14260==    by 0x8E7859B: gst_tee_handle_data (gsttee.c:658)
==14260==    by 0x8E78920: gst_tee_chain (gsttee.c:730)
==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
==14260==    by 0x7E685CE: gst_ts_demux_push_pending_data (tsdemux.c:1763)
==14260==    by 0x7E68961: gst_ts_demux_handle_packet (tsdemux.c:1802)
==14260==    by 0x7E68A82: gst_ts_demux_push (tsdemux.c:1840)
==14260==    by 0x7E5C940: mpegts_base_chain (mpegtsbase.c:1125)
==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
==14260==    by 0x723704F: gst_base_src_loop (gstbasesrc.c:2785)
==14260==    by 0x4EE6047: gst_task_func (gsttask.c:316)
==14260==    by 0x4EE7142: default_func (gsttaskpool.c:70)
==14260==    by 0x59379BD: g_thread_pool_thread_proxy (gthreadpool.c:309)
==14260==    by 0x59373D2: g_thread_proxy (gthread.c:798)
==14260==    by 0x601BDA5: start_thread (in /lib64/libpthread-2.15.so)
==14260==
==14260== 320 (32 direct, 288 indirect) bytes in 1 blocks are
definitely lost in loss record 2,496 of 2,576
==14260==    at 0x4C2C5DB: malloc (vg_replace_malloc.c:270)
==14260==    by 0x591221A: g_malloc (gmem.c:159)
==14260==    by 0x592AC50: g_slice_alloc (gslice.c:1003)
==14260==    by 0x4ED542F: gst_structure_new_id_empty_with_size
(gststructure.c:147)
==14260==    by 0x4ED551A: gst_structure_new_id_empty (gststructure.c:174)
==14260==    by 0x4ED6FA2: gst_structure_new_id (gststructure.c:757)
==14260==    by 0x4E95658: gst_event_new_segment (gstevent.c:711)
==14260==    by 0x7E6767B: calculate_and_push_newsegment (tsdemux.c:1652)
==14260==    by 0x7E67C4D: gst_ts_demux_push_pending_data (tsdemux.c:1731)
==14260==    by 0x7E68961: gst_ts_demux_handle_packet (tsdemux.c:1802)
==14260==    by 0x7E68A82: gst_ts_demux_push (tsdemux.c:1840)
==14260==    by 0x7E5C940: mpegts_base_chain (mpegtsbase.c:1125)
==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
==14260==    by 0x723704F: gst_base_src_loop (gstbasesrc.c:2785)
==14260==    by 0x4EE6047: gst_task_func (gsttask.c:316)
==14260==    by 0x4EE7142: default_func (gsttaskpool.c:70)
==14260==    by 0x59379BD: g_thread_pool_thread_proxy (gthreadpool.c:309)
==14260==    by 0x59373D2: g_thread_proxy (gthread.c:798)
==14260==    by 0x601BDA5: start_thread (in /lib64/libpthread-2.15.so)
==14260==
==14260== LEAK SUMMARY:
==14260==    definitely lost: 104 bytes in 4 blocks
==14260==    indirectly lost: 288 bytes in 4 blocks
==14260==      possibly lost: 0 bytes in 0 blocks

--
Andrey Utkin
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why this events leak happen?

Thiago Santos
On 01/16/2014 01:05 AM, Andrey Utkin wrote:

> I am still not 100% sure this is a GStreamer bug, although partially
> very likely.
>
> Trying to simulate the situation in my app, i made up the following
> gst-launch command:
>
> GST_DEBUG=3 G_SLICE=always-malloc valgrind --show-reachable=no
> --suppressions=gst.supp gst-launch-1.0 udpsrc uri=udp://225.1.1.1:1234
> multicast-iface=lo ! tsdemux name=demux demux.video_0100 ! tee name=t
> t.src_0 ! h264parse ! avdec_h264 ! fakesink  t.src_1 ! h264parse !
> avdec_h264 ! fakesink   t.src_2 ! h264parse ! avdec_h264 ! fakesink
> t.src_3 ! h264parse ! avdec_h264 ! fakesink
>
> Input is just MPEG TS with H.264 stream. (I avoided videotestsrc here
> because it produces valgrind false positives by itself. But you should
> be able to use it with same result, too). The demuxed result is Tee'ed
> 4 times. In valgrind log, you see below log.
>
> In my real app, i have same
> gst_video_decoder_sink_event_default-related leak, and some others
> (gst_event_new_caps, gst_event_new_stream_start,
> gst_h264_parse_update_src_caps - for them i cannot produce testcase
> and can consider a bug in my app).
>
> gst-everything is from today's git master.

Hi,

I tried to reproduce your issue with videotestsrc or with a ts file
but was unable to see leaks in videodecoder.
Perhaps it only happens with your file? Can you share it? What
else are you doing to reproduce it? Do you let it play till the end
or do you abort the pipeline?
Does it happen if played with filesrc instead of from udp?

--
Thiago

>
> Thanks for any help.
>
> ==14260== HEAP SUMMARY:
> ==14260==     in use at exit: 625,643 bytes in 4,825 blocks
> ==14260==   total heap usage: 85,654 allocs, 80,829 frees, 24,134,262
> bytes allocated
> ==14260==
> ==14260== 72 bytes in 3 blocks are definitely lost in loss record 1,798 of 2,576
> ==14260==    at 0x4C2C5DB: malloc (vg_replace_malloc.c:270)
> ==14260==    by 0x591221A: g_malloc (gmem.c:159)
> ==14260==    by 0x592AC50: g_slice_alloc (gslice.c:1003)
> ==14260==    by 0x5905FB2: g_list_prepend (glist.c:279)
> ==14260==    by 0x84E2491: gst_video_decoder_sink_event_default
> (gstvideodecoder.c:1172)
> ==14260==    by 0x84E2606: gst_video_decoder_sink_event (gstvideodecoder.c:1204)
> ==14260==    by 0x4EB4F2B: gst_pad_send_event_unchecked (gstpad.c:5051)
> ==14260==    by 0x4EB416E: gst_pad_push_event_unchecked (gstpad.c:4747)
> ==14260==    by 0x4EAF9A4: push_sticky (gstpad.c:3380)
> ==14260==    by 0x4EA75F4: events_foreach (gstpad.c:533)
> ==14260==    by 0x4EAFD2E: check_sticky (gstpad.c:3436)
> ==14260==    by 0x4EB4609: gst_pad_push_event (gstpad.c:4864)
> ==14260==    by 0x720FD73: gst_base_parse_push_pending_events
> (gstbaseparse.c:2025)
> ==14260==    by 0x7210E78: gst_base_parse_push_frame (gstbaseparse.c:2203)
> ==14260==    by 0x7210608: gst_base_parse_handle_and_push_frame
> (gstbaseparse.c:2131)
> ==14260==    by 0x72120A8: gst_base_parse_finish_frame (gstbaseparse.c:2453)
> ==14260==    by 0x909F3D4: gst_h264_parse_handle_frame (gsth264parse.c:959)
> ==14260==    by 0x720F9A7: gst_base_parse_handle_buffer (gstbaseparse.c:1959)
> ==14260==    by 0x72144F3: gst_base_parse_chain (gstbaseparse.c:2880)
> ==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
> ==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
> ==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
> ==14260==    by 0x8E78366: gst_tee_do_push (gsttee.c:586)
> ==14260==    by 0x8E7859B: gst_tee_handle_data (gsttee.c:658)
> ==14260==    by 0x8E78920: gst_tee_chain (gsttee.c:730)
> ==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
> ==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
> ==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
> ==14260==    by 0x7E685CE: gst_ts_demux_push_pending_data (tsdemux.c:1763)
> ==14260==    by 0x7E68961: gst_ts_demux_handle_packet (tsdemux.c:1802)
> ==14260==    by 0x7E68A82: gst_ts_demux_push (tsdemux.c:1840)
> ==14260==    by 0x7E5C940: mpegts_base_chain (mpegtsbase.c:1125)
> ==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
> ==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
> ==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
> ==14260==    by 0x723704F: gst_base_src_loop (gstbasesrc.c:2785)
> ==14260==    by 0x4EE6047: gst_task_func (gsttask.c:316)
> ==14260==    by 0x4EE7142: default_func (gsttaskpool.c:70)
> ==14260==    by 0x59379BD: g_thread_pool_thread_proxy (gthreadpool.c:309)
> ==14260==    by 0x59373D2: g_thread_proxy (gthread.c:798)
> ==14260==    by 0x601BDA5: start_thread (in /lib64/libpthread-2.15.so)
> ==14260==
> ==14260== 320 (32 direct, 288 indirect) bytes in 1 blocks are
> definitely lost in loss record 2,496 of 2,576
> ==14260==    at 0x4C2C5DB: malloc (vg_replace_malloc.c:270)
> ==14260==    by 0x591221A: g_malloc (gmem.c:159)
> ==14260==    by 0x592AC50: g_slice_alloc (gslice.c:1003)
> ==14260==    by 0x4ED542F: gst_structure_new_id_empty_with_size
> (gststructure.c:147)
> ==14260==    by 0x4ED551A: gst_structure_new_id_empty (gststructure.c:174)
> ==14260==    by 0x4ED6FA2: gst_structure_new_id (gststructure.c:757)
> ==14260==    by 0x4E95658: gst_event_new_segment (gstevent.c:711)
> ==14260==    by 0x7E6767B: calculate_and_push_newsegment (tsdemux.c:1652)
> ==14260==    by 0x7E67C4D: gst_ts_demux_push_pending_data (tsdemux.c:1731)
> ==14260==    by 0x7E68961: gst_ts_demux_handle_packet (tsdemux.c:1802)
> ==14260==    by 0x7E68A82: gst_ts_demux_push (tsdemux.c:1840)
> ==14260==    by 0x7E5C940: mpegts_base_chain (mpegtsbase.c:1125)
> ==14260==    by 0x4EB12A4: gst_pad_chain_data_unchecked (gstpad.c:3773)
> ==14260==    by 0x4EB1F37: gst_pad_push_data (gstpad.c:4006)
> ==14260==    by 0x4EB2488: gst_pad_push (gstpad.c:4109)
> ==14260==    by 0x723704F: gst_base_src_loop (gstbasesrc.c:2785)
> ==14260==    by 0x4EE6047: gst_task_func (gsttask.c:316)
> ==14260==    by 0x4EE7142: default_func (gsttaskpool.c:70)
> ==14260==    by 0x59379BD: g_thread_pool_thread_proxy (gthreadpool.c:309)
> ==14260==    by 0x59373D2: g_thread_proxy (gthread.c:798)
> ==14260==    by 0x601BDA5: start_thread (in /lib64/libpthread-2.15.so)
> ==14260==
> ==14260== LEAK SUMMARY:
> ==14260==    definitely lost: 104 bytes in 4 blocks
> ==14260==    indirectly lost: 288 bytes in 4 blocks
> ==14260==      possibly lost: 0 bytes in 0 blocks
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why this events leak happen?

Andrey Utkin
2014/1/16 Thiago Santos <[hidden email]>:
> Hi,
>
> I tried to reproduce your issue with videotestsrc or with a ts file
> but was unable to see leaks in videodecoder.
> Perhaps it only happens with your file? Can you share it? What
> else are you doing to reproduce it? Do you let it play till the end
> or do you abort the pipeline?
> Does it happen if played with filesrc instead of from udp?

Thank you for your interest.
Doesn't happen with filesrc.
You can get the same source stream by running such commands:

either

ffmpeg \
    -re -f lavfi -i testsrc \
    -re -f lavfi -i aevalsrc="0.1*sin(2*PI*(360-2.5/2)*t) |
0.1*sin(2*PI*(360+2.5/2)*t)" \
    -re -f lavfi -i aevalsrc="sin(10*2*PI*t)*sin(880*2*PI*t)" \
    -re -f lavfi -i aevalsrc="sin(440*2*PI*t):s=44100" \
    -map 0:0 \
    -map 1:0 \
    -map 2:0 \
    -map 3:0 \
    -vcodec libx264 \
    -acodec aac \
    -strict -2 \
    -f mpegts udp://225.1.1.1:1234?localaddr=127.0.0.1

(audio streams shouldn't matter, so you should be able to leave just
"-re -f lavfi -i testsrc" input and drop audio ones)

or

while true; do wget -q -O - http://whdd.org/test.ts; done | pv -L
35000 | /usr/local/src/ffmpeg/tools/aviocat pipe:0
'udp://225.1.1.1:1234?localaddr=127.0.0.1&pkt_size=1316'

Having source up, launch above valgrind command and let it work ~20
seconds (so that h264parse "no SPS/PPS yet" warnings stop appearing).
Then interrupt valgrind with Ctrl+C.

--
Andrey Utkin
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why this events leak happen?

Thiago Santos
On 01/16/2014 11:57 AM, Andrey Utkin wrote:

> 2014/1/16 Thiago Santos <[hidden email]>:
>> Hi,
>>
>> I tried to reproduce your issue with videotestsrc or with a ts file
>> but was unable to see leaks in videodecoder.
>> Perhaps it only happens with your file? Can you share it? What
>> else are you doing to reproduce it? Do you let it play till the end
>> or do you abort the pipeline?
>> Does it happen if played with filesrc instead of from udp?
> Thank you for your interest.
> Doesn't happen with filesrc.
> You can get the same source stream by running such commands:
>
> either
>
> ffmpeg \
>      -re -f lavfi -i testsrc \
>      -re -f lavfi -i aevalsrc="0.1*sin(2*PI*(360-2.5/2)*t) |
> 0.1*sin(2*PI*(360+2.5/2)*t)" \
>      -re -f lavfi -i aevalsrc="sin(10*2*PI*t)*sin(880*2*PI*t)" \
>      -re -f lavfi -i aevalsrc="sin(440*2*PI*t):s=44100" \
>      -map 0:0 \
>      -map 1:0 \
>      -map 2:0 \
>      -map 3:0 \
>      -vcodec libx264 \
>      -acodec aac \
>      -strict -2 \
>      -f mpegts udp://225.1.1.1:1234?localaddr=127.0.0.1
>
> (audio streams shouldn't matter, so you should be able to leave just
> "-re -f lavfi -i testsrc" input and drop audio ones)
>
> or
>
> while true; do wget -q -O - http://whdd.org/test.ts; done | pv -L
> 35000 | /usr/local/src/ffmpeg/tools/aviocat pipe:0
> 'udp://225.1.1.1:1234?localaddr=127.0.0.1&pkt_size=1316'
>
> Having source up, launch above valgrind command and let it work ~20
> seconds (so that h264parse "no SPS/PPS yet" warnings stop appearing).
> Then interrupt valgrind with Ctrl+C.
Thanks for the tips on reproducing, found the leak and fixed with
commit 47f720a8f00d3e942fc378c873bed0ab62ba5cf1 to -base.

--
Regards,
Thiago

>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why this events leak happen?

Andrey Utkin
2014/1/17 Thiago Santos <[hidden email]>:
> Thanks for the tips on reproducing, found the leak and fixed with
> commit 47f720a8f00d3e942fc378c873bed0ab62ba5cf1 to -base.

I comfirm that the issue is fixed.
Thank you.

--
Andrey Utkin
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel