<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> 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): <div class="moz-text-html" lang="x-western"> <div class="WordSection1"> 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 </div> </div> <div class="moz-cite-prefix">Am 03.05.2017 um 00:30 schrieb Tim Müller: </div> <blockquote type="cite" cite="mid:1493764246.9388.26.camel@centricular.com"> <pre wrap="">On Tue, 2017-05-02 at 23:59 +0200, Martin Maurer wrote: Hi Martin, </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap=""> 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 </pre> </blockquote> </body> </html>