After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788708 - h264parse memory leak
h264parse memory leak
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-10-09 11:40 UTC by Nicola
Modified: 2017-10-09 16:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicola 2017-10-09 11:40:03 UTC 
valgrind output

==14216== 105,224 (3,808 direct, 101,416 indirect) bytes in 14 blocks are definitely lost in loss record 8,768 of 8,775
==14216==    at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14216==    by 0x58B42F9: g_malloc (in /usr/lib/libglib-2.0.so.0.5400.0)
==14216==    by 0x5895706: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5400.0)
==14216==    by 0x52E82FA: gst_buffer_new (gstbuffer.c:798)
==14216==    by 0x52E96A5: gst_buffer_new_allocate (gstbuffer.c:846)
==14216==    by 0x14877D24: gst_h264_parse_wrap_nal (gsth264parse.c:430)
==14216==    by 0x14879B1A: gst_h264_parse_process_nal (gsth264parse.c:896)
==14216==    by 0x1487BBE0: gst_h264_parse_handle_frame_packetized (gsth264parse.c:995)
==14216==    by 0x1487BBE0: gst_h264_parse_handle_frame (gsth264parse.c:1078)
==14216==    by 0x505D6FF: gst_base_parse_handle_buffer (gstbaseparse.c:2147)
==14216==    by 0x50634EA: gst_base_parse_chain (gstbaseparse.c:3229)
==14216==    by 0x5320D6A: gst_pad_chain_data_unchecked (gstpad.c:4205)
==14216==    by 0x5320D6A: gst_pad_push_data (gstpad.c:4461)
==14216==    by 0x5328E52: gst_pad_push (gstpad.c:4580)
==14216==    by 0x1322FC98: gst_rtp_base_depayload_push (gstrtpbasedepayload.c:788)
==14216==    by 0x13230090: gst_rtp_base_depayload_handle_buffer.isra.4 (gstrtpbasedepayload.c:440)
==14216==    by 0x5320D6A: gst_pad_chain_data_unchecked (gstpad.c:4205)
==14216==    by 0x5320D6A: gst_pad_push_data (gstpad.c:4461)
==14216==    by 0x5328E52: gst_pad_push (gstpad.c:4580)
==14216==    by 0x1278DB08: gst_queue_push_one (gstqueue.c:1395)
==14216==    by 0x1278DB08: gst_queue_loop (gstqueue.c:1548)
==14216==    by 0x5354358: gst_task_func (gsttask.c:335)


the pipeline is like this:

rtspsrc ! rtph264depay ! h264parse ! matroskamux
Comment 1 Nicola 2017-10-09 12:52:06 UTC 
this seems a false positive, sorry for the noise,

when h264parse reachs that code it produces a buffer with an invalid timestamp, 

in my app I cannot accept such buffers and I forgot to unref in error case,

maybe we could investigate why h264parse outputs buffers with invalid timestamps in some cases but this isn't a memory leak
Comment 2 Tim-Philipp Müller 2017-10-09 16:24:00 UTC 
Please open a new bug for the timestamp issue, ideally with a way to reproduce (I've heard of this before).