gst_fake_sink_render: who releases the incoming buffers/memory?
Martin Maurer
meinemailingliste2 at online.de
Wed May 3 06:30:40 UTC 2017
Hello Tim
many thanks for your helpful answer. I was able to continue my analysis.
I have a leak in proprietary code, which I try to solve. It is leaking
GstBuffers, GstMemory and a lot more.
Here is an output (filtered by "2DE02E0" which is reported by leak
tracer at end of log):
Line 4879: 0:00:00.801076398 9452 0000000002C78F00 LOG
GST_BUFFER gstbuffer.c:799:gst_buffer_new: new 0000000002DE02E0
Line 4880: 0:00:00.801194912 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:414:_memory_add: buffer
0000000002DE02E0, idx -1, mem 000000000DE70040
Line 4881: 0:00:00.801313790 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:855:gst_buffer_new_allocate:
new buffer 0000000002DE02E0 of size 3156480 from allocator 0000000000000000
Line 4884: 0:00:00.801730595 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:1721:gst_buffer_map_range:
buffer 0000000002DE02E0, idx 0, length 1, flags 0002
Line 4885: 0:00:00.801849473 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:213:_get_merged_memory: buffer
0000000002DE02E0, idx 0, length 1
Line 4887: 0:00:00.802088324 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:1721:gst_buffer_map_range:
buffer 0000000002DE02E0, idx 0, length 1, flags 0002
Line 4888: 0:00:00.802232364 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:213:_get_merged_memory: buffer
0000000002DE02E0, idx 0, length 1
Line 4890: 0:00:00.802511693 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:351:gst_mini_object_ref:
0000000002DE02E0 ref 1->2
Line 4908: 0:00:00.806898166 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:431:gst_mini_object_unref:
0000000002DE02E0 unref 2->1
Line 4924: 0:00:00.811793338 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:1721:gst_buffer_map_range:
buffer 0000000002DE02E0, idx 0, length 1, flags 0001
Line 4925: 0:00:00.812246973 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:213:_get_merged_memory: buffer
0000000002DE02E0, idx 0, length 1
Line 4927: 0:00:00.813025153 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:1721:gst_buffer_map_range:
buffer 0000000002DE02E0, idx 0, length 1, flags 0001
Line 4928: 0:00:00.813394187 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:213:_get_merged_memory: buffer
0000000002DE02E0, idx 0, length 1
Line 4930: 0:00:00.814017753 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:351:gst_mini_object_ref:
0000000002DE02E0 ref 1->2
Line 4934: 0:00:00.817231850 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:431:gst_mini_object_unref:
0000000002DE02E0 unref 2->1
Line 21073: 0:00:04.460508975 9452 000000000032B030
TRACE GST_TRACER :0:: object-alive,
type-name=(string)GstBuffer, address=(gpointer)0000000002DE02E0,
description=(string)buffer: 0000000002DE02E0, pts 0:00:00.016666666, dts
99:99:99.999999999, dur 0:00:00.016666667, size 3156480, offset 1,
offset_end 2, flags 0x0, ref-count=(uint)1, trace=(string);
Inside GstBuffer there seems to be a GstMemory. So here is an output
(filtered by "DE70040" which is also reported by leak tracer at end of
log and added to the above GstBuffer, see first line):
Line 4880: 0:00:00.801194912 9452 0000000002C78F00
LOG GST_BUFFER gstbuffer.c:414:_memory_add: buffer
0000000002DE02E0, idx -1, mem 000000000DE70040
Line 4886: 0:00:00.801968352 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:351:gst_mini_object_ref:
000000000DE70040 ref 1->2
Line 4889: 0:00:00.802365100 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:351:gst_mini_object_ref:
000000000DE70040 ref 2->3
Line 4906: 0:00:00.806293198 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:431:gst_mini_object_unref:
000000000DE70040 unref 3->2
Line 4907: 0:00:00.806549918 9452 0000000002C78F00 TRACE
GST_REFCOUNTING gstminiobject.c:431:gst_mini_object_unref:
000000000DE70040 unref 2->1
Line 4926: 0:00:00.812676540 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:351:gst_mini_object_ref:
000000000DE70040 ref 1->2
Line 4929: 0:00:00.813721286 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:351:gst_mini_object_ref:
000000000DE70040 ref 2->3
Line 4932: 0:00:00.816408452 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:431:gst_mini_object_unref:
000000000DE70040 unref 3->2
Line 4933: 0:00:00.816641469 9452 0000000002C78F00
TRACE GST_REFCOUNTING gstminiobject.c:431:gst_mini_object_unref:
000000000DE70040 unref 2->1
Line 21087: 0:00:04.462267722 9452 000000000032B030
TRACE GST_TRACER :0:: object-alive,
type-name=(string)GstMemory, address=(gpointer)000000000DE70040,
description=(string)000000000DE70040, ref-count=(uint)1, trace=(string);
Pay attention, both times same run, only filtered differently. This are
the only places, where the both addresses occur in memory.
So buffer is not reused, but seems to remain occupied.
I see ref counts going up from 1 to x and back down to 1, which seems to
be correct? What else could I trace or is attached to GstBuffer or
GstMemory,
which could prevent the GstBuffer and GstMemory from being reported as
memory leaks?
The number of leaked buffers looks like to be independently from the
amount of buffers I am using in videotestsrc.
I am seeing big buffers and small buffers (due to I used a H.264
encoding element in the middle).
Best regards,
Martin
Am 03.05.2017 um 00:30 schrieb Tim Müller:
> On Tue, 2017-05-02 at 23:59 +0200, Martin Maurer wrote:
>
> Hi Martin,
>
>> gst-launch-1.0 videotestsrc num-buffers=100 ! xxx ! fakesink
>> silent=false -v
>>
>> Videotestsrc is generating buffers, xxx (not relevant what it is,
>> e.g.
>> openh264enc) is forwarding buffers
>> and fakesink is consuming the buffers.
>> Looking into latest source code, function gst_fake_sink_render, I
>> can't find where the buffers/memory is released.
>> Is it done somewhere outside the fakesink source code?
>> Where do I find this place, where fakesink render function is called
>> and buffer/memory is released afterwards?
>> (don't know if relevant: I have internal leak checking on and use
>> also some GST_DEBUG options)
>> Is there some documentation which explains such deep internals of
>> Gstreamer?
> The fakesink element takes ownership of the buffer pushed onto its
> sinkpad (like all elements), and the GstBaseSink class will take care
> of calling the fakesink element's render function and then later of
> releasing the buffer.
>
> The "enable-last-sample" property defaults to true, so basesink will
> hold onto the last buffer until the next buffer comes in, unless this
> is disabled.
>
> Cheers
> -Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170503/91ae91f0/attachment.html>
More information about the gstreamer-devel
mailing list