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 600728 - gvfsd-smb memory leak
gvfsd-smb memory leak
Status: RESOLVED NOTGNOME
Product: gvfs
Classification: Core
Component: smb backend
1.4.x
Other Linux
: Normal major
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2009-11-04 19:47 UTC by Peter Runge
Modified: 2014-07-03 21:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gvfsd-smb Valgrind output (331.02 KB, text/plain)
2009-11-04 19:47 UTC, Peter Runge
Details
gvfsd-smb console output file (52 bytes, text/plain)
2009-11-04 19:48 UTC, Peter Runge
Details
Valgrind log with debug symbols (272.82 KB, text/plain)
2009-11-05 08:59 UTC, Peter Runge
Details
Screenshot of memory use. (791.59 KB, image/png)
2010-01-20 02:59 UTC, paulbaranowski
Details

Description Peter Runge 2009-11-04 19:47:54 UTC
Created attachment 146944 [details]
 gvfsd-smb Valgrind output

(description copied from
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/474021)

Mounted an SMB share using gvfs-mount (also same effect when done through
Places/Network menu item in Gnome). When copying large files from my hard disk
to the network share using ~/.gvfs/[share] memory usage of the gvfsd-smb
process becomes large (had over 4G at one point) which could be a memory leak.
This is repeatable - I tried rebooting and the process grows again when doing
the copy.

Ran valgrind with --leak-check=full over gvfsd-smb. Results attached - seems to
indicate a leak in smbc_set_credentials_with_fallback call in
/usr/lib/libsmbclient.so.0. Console out (redirected to file from a script) from
gvfsd-smb execution has one line "smbc_set_credentials_with_fallback:
allocation fail". Could this be a bug in libsmbclient instead of gvfs?

Running libsmbclient 2:3.4.0-3ubuntu5, gvfs 1.4.1-0ubuntu1 on Ubuntu 9.10.
Never experienced this leak before when copying large files in 9.04, only after
upgrading to 9.10.
Comment 1 Peter Runge 2009-11-04 19:48:55 UTC
Created attachment 146945 [details]
gvfsd-smb console output file
Comment 2 Peter Runge 2009-11-05 08:59:38 UTC
Created attachment 146987 [details]
Valgrind log with debug symbols

Added another Valgrind log, this time run with debug symbols.
Comment 3 paulbaranowski 2010-01-20 02:56:20 UTC
I have also experienced this bug on Ubuntu 9.10.  I discovered that it is tied to the *number* of files being copied and not the size of the files being copied.  I am attaching a screenshot of the memory consumed.
Comment 4 paulbaranowski 2010-01-20 02:59:00 UTC
Created attachment 151807 [details]
Screenshot of memory use.
Comment 5 Oded Arbel 2010-01-20 17:53:40 UTC
I can see the same problem. I don't think it is necessarily related to the number of files being copied, but probably to the number of writes - for example, when I download an active torrent to the gvfsd-smb mounted share, I can see the memory of gvfsd-smb grows at about 20~30 KB per second. It also starts to get slow as more memory is used.
Comment 6 Anton 2010-02-23 20:24:29 UTC
I'm also seeing this problem on Ubuntu 9.10 (AMD64).

I see this problem even with very little reading or writing to the network share. Opening and saving a couple of dozen small text files (eg less than 10kB) will over a couple of days cause gvfs-smb to use 2+GB of memory.

The network share is on a Samba 3.3 server and authenticated via Kerberos (in case that matters).
Comment 7 Tomas Bzatek 2012-12-03 17:39:02 UTC
(In reply to comment #2)
> Created an attachment (id=146987) [details]
> Valgrind log with debug symbols

Looking at the biggest chunk at the end, do_write(), this seems to be a problem in libsmbclient actually. The code of our do_write() method is actually very simple and nothing to be freed. Moreover, the backend doesn't hold any buffered data itself.

Can you please check with reasonable new smbclient version (i.e. samba 3.6) to see if it's still valid?
Comment 8 Tobias Mueller 2013-04-03 15:22:15 UTC
So this is NOTGNOME then..?
Comment 9 Tomas Bzatek 2013-04-03 15:44:21 UTC
(In reply to comment #8)
> So this is NOTGNOME then..?

Perhaps, I'm still eager to see the results from reporters.