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 790484 - gvfsd-mtp memory leak fills up whole memory and then gets killed
gvfsd-mtp memory leak fills up whole memory and then gets killed
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: mtp backend
1.34.x
Other Linux
: Normal normal
: ---
Assigned To: Philip Langdale
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2017-11-17 09:51 UTC by xyzdragon
Modified: 2018-09-21 18:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
For whose you who want to enjoy a realtime memory "progress" bar (637.68 KB, video/mp4)
2017-11-17 09:51 UTC, xyzdragon
Details
gvfs log (445.28 KB, application/gzip)
2018-08-22 15:43 UTC, Foulques
Details

Description xyzdragon 2017-11-17 09:51:16 UTC
Created attachment 363899 [details]
For whose you who want to enjoy a realtime memory "progress" bar

After plugging in my smartphone I can see my memory feeling up in realtime, roughly 30MB per second. After several minutes my RAM is full, Linux completely freezes up and gvfsd-mtp gets killed by the kernel or so it seems.

I'm currently using gvfs 1.30.3-1. I already tried to install the new version using apt which would be 1.34.1-1+b1, but it seems like the binaries don't get replaced? I'm not sure, /usr/lib/gvfs/gvfsd-mtp has timestamp 2017-11-15T16:55 or is it the timestamp when it was last compiled by the package creator, would be quite recent then, actually sounds plausible. Would welcome suggestion how to check the version of a running gvfsd process.

uname -a
Linux user-pc 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64 GNU/Linux

I think this message from /var/log/syslog might be important:

    Nov 17 10:10:45 user-pc org.gtk.vfs.Daemon[2203]: Error 1: Get Storage information failed.
    Nov 17 10:10:45 user-pc gvfsd-computer[16086]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

Now that I have this problem, how can I stop gvfs from automounting MTP?!
Comment 1 xyzdragon 2017-11-17 09:57:14 UTC
Forgot to tell, but the MTP device is actually usable over caja while the memory is still loading up!

Also:

cat /usr/share/gvfs/mounts/mtp.mount
    [Mount]
    Type=mtp
    Exec=/usr/lib/gvfs/gvfsd-mtp
    AutoMount=false

So, with AutoMount=false, while is it still mounted? I didn't even set it to false, it always was false.
Comment 2 xyzdragon 2017-11-17 10:06:29 UTC
dconf dump / | grep mount
    automount-open=false

Everything is set to false. I don't know how to stop this automtount.
I'm using Debian minimal installation with manually installed XFCE 4.12.1-1

Ok, I disabled automount now with `kill $(pgrep gvfs-mtp-volume)`. I guess I'll have to put this in my autostart list ...
Comment 3 xyzdragon 2017-11-17 10:25:13 UTC
killing gvfs-mtp-volume-monitor does not work for long. It gets autorespawned. This is getting really obnoxious.
Comment 4 xyzdragon 2017-11-17 10:30:26 UTC
Sorry for spamming so much, but this keeps me restless. Last resort:

la /usr/lib/gvfs/gvfs-mtp-volume-monitor
    -rwxr-xr-x 1 root root 99K Nov 15 16:55 /usr/lib/gvfs/gvfs-mtp-volume-monitor
sudo chmod a-rx /usr/lib/gvfs/gvfs-mtp-volume-monitor
la /usr/lib/gvfs/gvfsd-mtp
    -rwxr-xr-x 1 root root 66K Nov 15 16:55 /usr/lib/gvfs/gvfsd-mtp
sudo chmod a-rx /usr/lib/gvfs/gvfsd-mtp
pkill gvfs-mtp-volume
Comment 5 Philip Langdale 2017-11-18 16:34:49 UTC
I don't doubt that you saw a memory leak, but I can't reproduce this, which means there's little we can do.

Your info says you're running a 4.5.x kernel which doesn't correspond to Jessie or Stretch, but something in-between. I can only assume the rest of your installation is in a similar state, so I'd suggest upgrading to Stretch and see what happens then, and if you still see the leak, upgrade gvfs and its dependencies to the latest versions from sid.
Comment 6 Ondrej Holy 2017-11-20 08:53:18 UTC
Maybe thunar-volman is responsible for automounting in XFCE, don't know:
http://goodies.xfce.org/projects/thunar-plugins/thunar-volman
Comment 7 Foulques 2018-08-20 17:18:04 UTC
I have the same bug under Linux Mint 19 Cinnamon. The whole memory (16GB) is filled really quickly (one minute or so).

The connected device is a HTC 10 with Android 8.0.0
Comment 8 Ondrej Holy 2018-08-22 08:03:39 UTC
This is really weird but we can't do much without any further info, I can't reproduce it either. Can you please provide gvfsd.log for the beginning, please? Please follow the steps on:
https://wiki.gnome.org/Projects/gvfs/debugging#Getting_debug_logs

If this doesn't help us I will tell you how you can obtain valgrind output, which may also be useful in this case
Comment 9 Foulques 2018-08-22 15:43:08 UTC
Created attachment 373426 [details]
gvfs log

Despite this problem, I can browse my device and copy files without problem.

Not sure if this lig can help. Tell if there is anything else I can do.

Thanks for your time !
Comment 10 Ondrej Holy 2018-08-23 06:52:52 UTC
Thanks for the log. The log contains more than 2,5 million lines with the following records:
mtp: (I) check_event: Read event needs to be issued.
mtp: (I) check_event: Read_Event_Async failed: -1

This is not really expected given the fact that the log was obtained within a few minutes, wasn't it? If it leaks just a few bytes in one iteration, it can easily fill the whole memory...

Philip, will you please take a look at it?
Comment 11 Foulques 2018-08-23 08:58:23 UTC
This log was obtain in only a few seconds, like four or five, otherwise it would have been too big to upload it here.
Comment 12 Ondrej Holy 2018-08-23 09:18:41 UTC
Ups. It loops on the following lines: 
https://gitlab.gnome.org/GNOME/gvfs/blob/master/daemon/gvfsbackendmtp.c#L647

"Read_Event_Async" obviously returns always "-1".

As per the docs: "For now, this non-blocking mechanism only works with libusb-1.0, and not any of the other usb library backends. Attempting to call this method with another backend will always return an error."
https://github.com/libmtp/libmtp/blob/master/src/libmtp.c#L2291

Mint should not use different USB library, but in any case, we can't loop there forever...
Comment 13 Philip Langdale 2018-08-25 03:35:02 UTC
True enough, but I really need to understand *why* it's failing. I seriously doubt it's due to the use of the wrong libusb - libusb-1.0 has been the only game in town for years.

Something else is going on, but we'd need additional logging from libmtp to establish which call is failing and why.

Foulques - what versions of libmtp, libusb-1 and gvfs do you have? I know it's not the latest gvfs as it's still using the old style device names. Are you in a position to upgrade?
Comment 14 Foulques 2018-08-27 08:56:09 UTC
libmtp       1.1.15-1
libusb-1.0-0 2:1.0.21-2
gvfs         1.36.1-0ubuntu1.1

I can upgrade if needed of course. I'll try to do it later today.
Comment 15 GNOME Infrastructure Team 2018-09-21 18:15:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/320.