GNOME Bugzilla – Bug 769238
memory increases every time I umount and mount my secondary hard disk.
Last modified: 2018-04-07 20:50:55 UTC
I have a secondary hard disk that I only use to compile things like firefox/libreoffice, etc... Relavant fstab line: /dev/mapper/cache /home/hussam/cache ext4 defaults,relatime 0 1 Every time I umount and mount it again, gvfs-udisks2-volume-monitor uses 0.5 to 1MB extra memory or so. I will attach a valgrind log. This is glib trunk and gvfs 1.29.4 release.
Created attachment 332233 [details] valgrind log.
This also happens with usb memory sticks. gvfs-udisks2-volume-monitor just ate 6MB mounting and ejecting my usb memory stick. I don't remember this being an issue on glib 2.48.
compiling with --disable-libmount heavily limits the leaks. Git logs pointed me to bug 522053. I will post there.
I think I found the problem, the reference to struct libmnt_table * in _g_get_unix_mounts() is being leaked systematically because I used mnt_context_get_table() to obtain it, instead of the recommended mnt_context_get_mtab() function. And because of that mistake, the call to mnt_free_context() later on won't free the newly-allocated table [1], something that will happen if I used mnt_context_get_mtab() instead [2]. Other than that, I can see that the libmount's context is also being leaked when early returning in case that the mtab/mountinfo/fstab can't be read, so I'll fix that too, although I suspect that particular leak was not affecting you in this case. [1] https://www.kernel.org/pub/linux/utils/util-linux/v2.21/libmount-docs/libmount-Library-high-level-context.html#mnt-context-get-table [2] https://www.kernel.org/pub/linux/utils/util-linux/v2.21/libmount-docs/libmount-Library-high-level-context.html#mnt-context-get-mtab
Created attachment 332242 [details] [review] gunixmounts: Do not leak libmount contexts nor tables Use mnt_context_get_mtab instead of using mnt_context_get_table(), since that's the recommended way of accessing mtab/mountinfo information, and also because that way the (struct libmnt_table *) will get automatically deallocated when calling mnt_free_context()
Created attachment 332243 [details] [review] gunixmounts: Ensure that libmount's context gets freed on early returns Otherwise, it will be leaked in case the relevant table (mtab, fstab) could not be retrieved for some reason.
Adding Matthias to CC, as he reviewed also the other patches
Created attachment 332244 [details] [review] gunixmounts: Do not leak libmount tables in _g_get_unix_mounts() Use mnt_context_get_mtab instead of using mnt_context_get_table(), since that's the recommended way of accessing mtab/mountinfo information, and also because that way the (struct libmnt_table *) will get automatically deallocated when calling mnt_free_context()
I tried the patches. The 4 or 5MB leak I saw when plugging in and ejecting my usb stick when down to 100KB. I got a new valgrind log except it now crashes when ran through valgrind and I have a coredump. It doesn't exit when running normally.
Created attachment 332256 [details] valgrind log with patches applied
Created attachment 332257 [details] gdb log I also ran it through gdb and ctrl+c a while after ejecting and removing the usb stick.
I also have a coredump from when it ran through valgrind. http://d-h.st/QVEB The attachment is too large for bugzilla (5.8MB) so I uploaded it to dev-host.
This is bug in GLib, not GVfs, let's change component to GLib....
Review of attachment 332243 [details] [review]: Looks good.
Review of attachment 332244 [details] [review]: Okay.
(In reply to Hussam Al-Tayeb from comment #9) > I tried the patches. The 4 or 5MB leak I saw when plugging in and ejecting > my usb stick when down to 100KB. You probably want to use a suppression file: https://github.com/dtrebbien/GNOME.supp
Attachment 332243 [details] pushed as ed75b16 - gunixmounts: Ensure that libmount's context gets freed on early returns Attachment 332244 [details] pushed as b28c76b - gunixmounts: Do not leak libmount tables in _g_get_unix_mounts()
Thanks a lot for the review, Emmanuele, just pushed the patches now. (In reply to Hussam Al-Tayeb from comment #9) > I tried the patches. The 4 or 5MB leak I saw when plugging in and ejecting > my usb stick when down to 100KB. Thanks a lot for testing and confirming this, Hussam. > I got a new valgrind log except it now crashes when ran through valgrind and > I have a coredump. It doesn't exit when running normally. That's weird. Have you enabled coredump collection with ulimit first?
(In reply to Mario Sánchez Prada from comment #18) nks a lot for testing and confirming this, Hussam. > > > I got a new valgrind log except it now crashes when ran through valgrind and > > I have a coredump. It doesn't exit when running normally. > > That's weird. Have you enabled coredump collection with ulimit first? I'm not sure. The usual behavior is getting coredumps. They get stored in /var/lib/systemd/coredump/. It just doesn't crash outside valgrind.
(In reply to Hussam Al-Tayeb from comment #9) > I got a new valgrind log except it now crashes when ran through valgrind and > I have a coredump. It doesn't exit when running normally. Maybe consider setting these in your environment to trigger the crash outside valgrind: MALLOC_CHECK_=2 export MALLOC_CHECK_ MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) export MALLOC_PERTURB_ (I have that blurb in my ~/.bash_profile.)
(In reply to Debarshi Ray from comment #20) > (In reply to Hussam Al-Tayeb from comment #9) > > I got a new valgrind log except it now crashes when ran through valgrind and > > I have a coredump. It doesn't exit when running normally. > > Maybe consider setting these in your environment to trigger the crash > outside valgrind: > > MALLOC_CHECK_=2 > export MALLOC_CHECK_ > > MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) > export MALLOC_PERTURB_ > > (I have that blurb in my ~/.bash_profile.) I will do that. Will that mean I have to restart gvfs from a terminal or are those variables read by every application on next run? Thank you.
It shouldn't be set on next run, it depends on activation environment of D-Bus user session. You can check the variables by: cat /proc/$(pidof gvfs-udisks2-volume-monitor)/environ | grep MALLOC Restarting GVfs from terminal should fix that if not set already: pkill gvfs; /usr/libexec/gvfsd &
It's been a year; is this still an issue?
Nope. It seems to be working much better now :) Thank you very much!