GNOME Bugzilla – Bug 790833
VmSize remains high after clean up
Last modified: 2017-11-26 22:11:48 UTC
Created attachment 364397 [details] source code Running the attached program with: gcc test.c `pkg-config --cflags --libs gstreamer-1.0` && ./a.out gives: VmSize: 29196 kB Gstreamer Playback: Starting Gstreamer Playback: receiving eos and stop Gstreamer Playback: ending Gstreamer Playback: post cleaning VmSize: 190900 kB Why VmSize is still so big (+160MB) after everything has been cleaned up?
What is the actual bug you're reporting? $ valgrind --leak-check=yes ./test LEAK SUMMARY: definitely lost: 16,384 bytes in 1 blocks [this is one-time allocs in glib] indirectly lost: 0 bytes in 0 blocks possibly lost: 4,228 bytes in 61 blocks still reachable: 551,489 bytes in 2,042 blocks of which reachable via heuristic: length64 : 280 bytes in 7 blocks newarray : 1,568 bytes in 18 blocks suppressed: 0 bytes in 0 blocks This looks fine to me. There are some fair bit of global allocations that will be around until the process ends, e.g. for the type system. Running multiple loops of the pipeline also doesn't increase anything. Maybe VMSize is simply not right for what you want to measure? Compare to Rss* You can check /proc/self/maps for details. Loading GStreamer plugins involves loading shared libs and those won't be unloaded ever. This is not really a problem.
OK. Thanks. You can close this bug. (I have a leak in my gstreamer-based application and despite all the usual tools, I have a hard time to find it). I might open another bug if I find something else suspicious in one of the plugins I'm using.)