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 639777 - gvfsd-http leaves lots of connections open
gvfsd-http leaves lots of connections open
Status: RESOLVED DUPLICATE of bug 695652
Product: gvfs
Classification: Core
Component: http backend
1.6.x
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
: 651863 (view as bug list)
Depends on: 687757
Blocks:
 
 
Reported: 2011-01-17 19:45 UTC by nodiscc
Modified: 2013-09-16 12:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gvfsd-http memory leak (156.42 KB, image/png)
2012-10-30 16:59 UTC, Jared González
Details

Description nodiscc 2011-01-17 19:45:16 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.
Comment 1 Jared González 2012-10-30 16:59:48 UTC
Created attachment 227657 [details]
gvfsd-http memory leak
Comment 2 André Klapper 2012-10-30 17:46:41 UTC
(In reply to comment #1)
> Created an attachment (id=227657) [details]
> gvfsd-http memory leak

Which gvfs version?
Comment 3 Lee Willis 2012-11-29 20:55:17 UTC
I can't comment on the memory leak, but certainly gvfs-backends 1.14.0-0ubuntu6 still leaves connections open, stuck in CLOSE_WAIT.
Comment 4 Tomas Bzatek 2012-12-05 16:49:53 UTC
(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.
Comment 5 Tomas Bzatek 2012-12-06 10:13:21 UTC
*** Bug 651863 has been marked as a duplicate of this bug. ***
Comment 6 ville.ranki 2013-06-01 17:43:25 UTC
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.
Comment 7 chrisw 2013-08-14 22:51:50 UTC
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?
Comment 8 Ondrej Holy 2013-09-10 13:44:26 UTC
(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?
Comment 9 ville.ranki 2013-09-16 08:29:27 UTC
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
Comment 10 Ondrej Holy 2013-09-16 12:57:11 UTC
(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 ***