After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 790833 - VmSize remains high after clean up
VmSize remains high after clean up
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-11-25 23:08 UTC by Gregoire
Modified: 2017-11-26 22:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
source code (1.60 KB, text/x-csrc)
2017-11-25 23:08 UTC, Gregoire
Details

Description Gregoire 2017-11-25 23:08:06 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?
Comment 1 Tim-Philipp Müller 2017-11-25 23:34:28 UTC
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.
Comment 2 Gregoire 2017-11-26 07:33:28 UTC
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.)