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 769238 - memory increases every time I umount and mount my secondary hard disk.
memory increases every time I umount and mount my secondary hard disk.
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
2.49.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-07-27 17:37 UTC by Hussam Al-Tayeb
Modified: 2018-04-07 20:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
valgrind log. (182.13 KB, application/x-compressed-tar)
2016-07-27 17:45 UTC, Hussam Al-Tayeb
  Details
gunixmounts: Do not leak libmount contexts nor tables (1.11 KB, patch)
2016-07-27 21:47 UTC, Mario Sánchez Prada
none Details | Review
gunixmounts: Ensure that libmount's context gets freed on early returns (1.58 KB, patch)
2016-07-27 21:47 UTC, Mario Sánchez Prada
committed Details | Review
gunixmounts: Do not leak libmount tables in _g_get_unix_mounts() (1.12 KB, patch)
2016-07-27 21:52 UTC, Mario Sánchez Prada
committed Details | Review
valgrind log with patches applied (191.51 KB, application/x-compressed-tar)
2016-07-28 07:41 UTC, Hussam Al-Tayeb
  Details
gdb log (2.80 KB, text/plain)
2016-07-28 07:42 UTC, Hussam Al-Tayeb
  Details

Description Hussam Al-Tayeb 2016-07-27 17:37:03 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.
Comment 1 Hussam Al-Tayeb 2016-07-27 17:45:49 UTC
Created attachment 332233 [details]
valgrind log.
Comment 2 Hussam Al-Tayeb 2016-07-27 18:13:54 UTC
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.
Comment 3 Hussam Al-Tayeb 2016-07-27 18:26:23 UTC
compiling with --disable-libmount heavily limits the leaks.
Git logs pointed me to bug 522053. I will post there.
Comment 4 Mario Sánchez Prada 2016-07-27 21:45:49 UTC
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
Comment 5 Mario Sánchez Prada 2016-07-27 21:47:27 UTC
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()
Comment 6 Mario Sánchez Prada 2016-07-27 21:47:47 UTC
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.
Comment 7 Mario Sánchez Prada 2016-07-27 21:48:27 UTC
Adding Matthias to CC, as he reviewed also the other patches
Comment 8 Mario Sánchez Prada 2016-07-27 21:52:55 UTC
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()
Comment 9 Hussam Al-Tayeb 2016-07-28 07:39:23 UTC
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.
Comment 10 Hussam Al-Tayeb 2016-07-28 07:41:11 UTC
Created attachment 332256 [details]
valgrind log with patches applied
Comment 11 Hussam Al-Tayeb 2016-07-28 07:42:25 UTC
Created attachment 332257 [details]
gdb log

I also ran it through gdb and ctrl+c a while after ejecting and removing the usb stick.
Comment 12 Hussam Al-Tayeb 2016-07-28 07:45:33 UTC
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.
Comment 13 Ondrej Holy 2016-07-28 07:59:50 UTC
This is bug in GLib, not GVfs, let's change component to GLib....
Comment 14 Emmanuele Bassi (:ebassi) 2016-07-28 08:27:21 UTC
Review of attachment 332243 [details] [review]:

Looks good.
Comment 15 Emmanuele Bassi (:ebassi) 2016-07-28 08:27:59 UTC
Review of attachment 332244 [details] [review]:

Okay.
Comment 16 Emmanuele Bassi (:ebassi) 2016-07-28 08:31:20 UTC
(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
Comment 17 Mario Sánchez Prada 2016-07-28 14:27:08 UTC
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()
Comment 18 Mario Sánchez Prada 2016-07-28 14:30:31 UTC
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?
Comment 19 Hussam Al-Tayeb 2016-07-28 14:35:07 UTC
(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.
Comment 20 Debarshi Ray 2017-04-09 10:35:51 UTC
(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.)
Comment 21 Hussam Al-Tayeb 2017-04-09 10:51:06 UTC
(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.
Comment 22 Ondrej Holy 2017-04-10 11:07:53 UTC
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 &
Comment 23 Emmanuele Bassi (:ebassi) 2018-04-01 07:39:18 UTC
It's been a year; is this still an issue?
Comment 24 Hussam Al-Tayeb 2018-04-01 09:08:45 UTC
Nope. It seems to be working much better now :)
Thank you very much!