GNOME Bugzilla – Bug 639777
gvfsd-http leaves lots of connections open
Last modified: 2013-09-16 12:57:11 UTC
Hello, I am running debian squeeze with gvfs-backends 1.6.4-3 installed. Im affected by a bug that makes gvfsd-http leave lots of connections in CLOSE_WAIT state. Steps to reproduce: 1. Search for videos with the Totem Youtube plugin 2. Close totem when it has found some videos. WHat happens: A long time (several hours) after totem was closed, i can still see many connections from gvfsd-http: $ netstat -anp --inet tcp 1 0 192.168.2.37:40750 209.85.146.102:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41261 209.85.229.93:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:43867 209.85.147.93:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:40752 209.85.146.102:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41290 209.85.229.93:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41276 209.85.229.93:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:35290 209.85.146.100:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:34309 209.85.229.101:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:33891 209.85.229.100:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:33909 209.85.229.100:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:57669 209.85.227.91:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:56108 209.85.229.91:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:35300 209.85.146.100:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:56106 209.85.229.91:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:40772 209.85.146.102:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:57635 209.85.227.91:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:48286 209.85.229.190:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:33924 209.85.229.100:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:58663 209.85.229.102:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:37235 209.85.227.102:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:35314 209.85.146.100:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:57594 209.85.229.136:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41295 209.85.229.93:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41273 209.85.146.138:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:57606 209.85.229.136:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41521 209.85.227.190:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41523 209.85.227.190:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41557 209.85.227.190:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:40757 209.85.146.102:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:40759 209.85.146.102:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:34292 209.85.229.101:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:34303 209.85.229.101:80 CLOSE_WAIT 25523/gvfsd-http tcp 1 0 192.168.2.37:41545 209.85.227.190:80 CLOSE_WAIT 25523/gvfsd-http What should normally happen: gvfsd-http should definitely close the unneeded sockets after sometime. It has been reported long time ago on Ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/571970 I'd be happy to provide more information, thanks for addressing this issue.
Created attachment 227657 [details] gvfsd-http memory leak
(In reply to comment #1) > Created an attachment (id=227657) [details] > gvfsd-http memory leak Which gvfs version?
I can't comment on the memory leak, but certainly gvfs-backends 1.14.0-0ubuntu6 still leaves connections open, stuck in CLOSE_WAIT.
(In reply to comment #3) > I can't comment on the memory leak, but certainly gvfs-backends 1.14.0-0ubuntu6 > still leaves connections open, stuck in CLOSE_WAIT. Just tried simple command `gvfs-cat http://www.google.com/` and it doesn't leave any connection open. In netstat, I can see the connection while downloading data but it disappears once transfer is complete. This is with gvfs master (1.15.0+), libsoup-2.40.2 and the patch from bug 687757 applied. Any chance you can test that? Would be interesting to see if using SoupRequest makes the issue go away. FYI, I can reproduce this with gvfs-1.14.1 and libsoup-2.40.1 and using old SoupInputStream method.
*** Bug 651863 has been marked as a duplicate of this bug. ***
I can reproduce this on gvfs-backends 1.16.1-0ubuntu1: - Start rhythmbox - Play a couple of internet radio streams (they don't play, but that's another bug i suppose) - Notice that gvfsd-http process is started - Quit rhythmbox - Notice that gvfsd-http is still running and it's memory usage keeps increasing.
I see the same as Comment 6. $ rpm -q libsoup gvfs libsoup-2.42.2-2.fc19.x86_64 gvfs-1.16.3-2.fc19.x86_64 It's easy to reproduce, anything helpful for debugging?
(In reply to comment #6) > I can reproduce this on gvfs-backends 1.16.1-0ubuntu1: > > - Start rhythmbox > - Play a couple of internet radio streams (they don't play, but that's another > bug i suppose) That's Bug 695652 and it's probably connected with. > - Notice that gvfsd-http process is started > - Quit rhythmbox > - Notice that gvfsd-http is still running and it's memory usage keeps > increasing. I can reproduce it only when trying to play radio stream, which don't work (Bug 695652). So I have lot of ESTABLISHED connections for gvfsd-http and memory is increasing. But I don't see any pending CLOSE_WAIT connections, so this has been fixed by the Bug 687757 probably. However when I try to play the "working" radio streams, there don't left any open connections and memory usage doesn't increasing. Are you able reproduce it in this case or is it duplicate of the Bug 695652?
Hi, I tested with a working radio (http://somafm.com/secretagent.pls). After quitting rhythmbox the gvfsd-http process is still alive: /usr/lib/gvfs/gvfsd-http --spawner :1.4 /org/gtk/gvfs/exec_spaw/4
(In reply to comment #9) > Hi, > > I tested with a working radio (http://somafm.com/secretagent.pls). After > quitting rhythmbox the gvfsd-http process is still alive: > > /usr/lib/gvfs/gvfsd-http --spawner :1.4 /org/gtk/gvfs/exec_spaw/4 This isn't bug, this process should be running once it is started and deal with new requests for the http scheme... So, marking as duplicate. *** This bug has been marked as a duplicate of bug 695652 ***