GNOME Bugzilla – Bug 680619
mpegaudioparse leaks memory
Last modified: 2012-10-28 15:43:31 UTC
Created attachment 219662 [details] Massif output I generated 1 hour test mp3 files with a 440 sine, at 32,64, and 128kbps. Using valgrind massif, I can see a steady increase in memory consumption. The gst-launch line is: valgrind --tool=massif --massif-out-file=memleak-128kbps.massif gst-launch-0.10 filesrc location=sine-128kbps-48khz-stereo-1hour.mp3 ! mpegaudioparse ! fakesink The line for creating the test files is: gst-launch-0.10 audiotestsrc samplesperbuffer=48000 num-buffers=3600 wave=sine ! \ "audio/x-raw-int, rate=(int)48000, channels=(int)2" ! lame bitrate=128 ! \ filesink location=sine-128kbps-48khz-stereo-1hour.mp3 Using ms_print to visualize the results, I see a linear increase from initially 1.95 MB to 4.11 MB. The massif and ms_print outputs are attached.
Created attachment 219663 [details] ms_print output
I see lots of slice allocator and registry output. Please rerun with G_SLICE=always-malloc to remove those false positives. Then there is the index, which is built incrementally while parsing the mp3, it should be freed when the pipeline is stopped.
Created attachment 219675 [details] massif result (processed by ms_print with G_SLICE=always-malloc used
Just looks like a GstIndex is being filled up (gst_index_add_associationv), which isn't a "leak" per-se. Its usage could be made more optimal though. Can you provide the unprocessed massif result ?
Created attachment 219751 [details] unprocessed massif result with G_SLICE=always-malloc used
According to IRC discussions, the index should not grow endlessly. I hope this is true :) Anyway, attached the unprocessed massif result, as requested.
right, so the increase in memory *is* due to GstIndex, which for each entry is allocating memory for: * The index entry. * The GTree entry in GstMemIndex. I tried on a 2hour file, and it results in 140 bytes per second. I'm not sure we really need a gazillion entries per file. Maybe introducing a limit of entry to the index would be a good idea.
*** This bug has been marked as a duplicate of bug 666053 ***