GNOME Bugzilla – Bug 736314
omxaudiodec: Does not unmap input buffers
Last modified: 2016-07-06 09:14:44 UTC
I suffer from memory leak of omxaacdec and I print log with --*REFCOUNT*:9, there is increasing refcount of allocatorsysmem. It only decreases once per like 3~5 increase. (filesrc ! aacparse ! omxaacdec ! fakesink) In the normal case of avdec_aac, the refcount of allocatorsysmem is not more than 6~7 as maximum. (filesrc ! aacparse ! avdec_aac ! fakesink) I believe the files I attached give great hints but it's really hard to decipher, demanding good understanding of the general pipeline process.
Created attachment 285722 [details] filesrc ! aacparse ! omxaacdec ! fakesink filesrc ! aacparse ! omxaacdec ! fakesink
Created attachment 285723 [details] filesrc ! aacparse ! avdec_aac ! fakesink
Needs further debugging to find where exactly the buffers (or more exact: the GstMemory) are leaked. They are the ones from the source, that the parser forwards (or should forward!) and then probably are leaked inside the decoder somewhere. Maybe in the code that stores them all in an adapter.
Created attachment 286162 [details] This is what I get from valgrind
This needs further debugging to see where exactly the memories of the source are leaked. Must be the parser or the input side of the decoder though. Maybe the parser does conversion in the omxaacdec case but not in the other. Can you check the caps in both cases?
OK slomo. I'm still working hard on this issue, but if you give me some points to look first I'll take a look at them. I have full gdb environment. About the caps, the pipeline is filesrc ! aacparse ! omxaacdec ! fakesink and the option -v shows me the below. /GstPipeline:pipeline0/GstAacParse:aacparse0.GstPad:src: caps = audio/mpeg, framed=(boolean)true, mpegversion=(int)4, rate=(int)44100, channels=(int)2, stream-format=(string)adts /GstPipeline:pipeline0/GstOMXAACDec-omxaacdec:omxaacdec-omxaacdec0.GstPad:sink: caps = audio/mpeg, framed=(boolean)true, mpegversion=(int)4, rate=(int)44100, channels=(int)2, stream-format=(string)adts and the sample aac file's properties are / # gst-typefind-1.0 /test.aac /test.aac - audio/mpeg, framed=(boolean)false, mpegversion=(int)4, stream-format=(string)adts, level=(string)2, base-profile=(string)lc, profile=(string)lc, channels=(int)2, rate=(int)44100 Thus, it seems like there wouldn't be conversion??
Yes, but the debug logs will tell you. I would add some printfs in the various places where the buffers go through to check the refcounts of the memories inside them. That should hint you at where it's leaked.
I found that my pipeline only unrefs the allocatorsysmem0 for the below stack, Breakpoint 10, gst_object_unref (object=0x20418) at gstobject.c:267 267 { (gdb) bt
+ Trace 234128
while it refs the allocator for the below three cases. #1 Breakpoint 11, gst_object_ref (object=object@entry=0x20418) at gstobject.c:242 242 { (gdb) bt
+ Trace 234129
so if the alloctor in/decreases its refcount by only gst_object_ref/unref, this information would be hopefully a great hint..
I'm relieved to know that the allocatorsysmem0 really changes it refcount by only gst_object_ref/unref, meaning that the above stack cases are the all happening to this object for refcount.
it refcount => its refcount
However what is leaked here is the memory, not the allocator. The allocator is a singleton.
Created attachment 287412 [details] [review] a patch that fixes the memory leak reported in this post. tracked the place where the refcount of parse->priv->cache->mem unnecessarily changes and found that one of functions in gstomxaudiodec.c doesn't gst_buffer_unmap() but only increases the mem's refcount by gst_buffer_map(), making it unable to be freed, later.
Added some further fixes on top (moved the unmap outside the loop and added it to all error cases) commit eba9e3f29d01f8eab2bf32e12c944ad6c5ea1fea Author: junji <jun.ji@lge.com> Date: Tue Sep 30 10:50:07 2014 +0900 omxaudiodec: Unmap input buffers after usage https://bugzilla.gnome.org/show_bug.cgi?id=736314