GNOME Bugzilla – Bug 660057
Requeueing messages might re-use disconnected connection
Last modified: 2011-11-22 17:03:15 UTC
Created attachment 197427 [details] [review] When requeueing don't assume same connection can be re-used. I am using gvfs-dav to connect to an Apache WebDAV server which apparently has a 2 seconds idle timeout (sigh). Therefore I run into this problem, when trying to connect to a password protected share: 1. Try to connect 2. Get authentication required dialog 3. Meanwhile: Server closes connection 4. Fill out username, password 5. libsoup tries to send on disconnected, fails with (process:21573): libsoup-CRITICAL **: soup_session_get_connection: assertion `soup_connection_get_state (item->conn) != SOUP_CONNECTION_DISCONNECTED' failed 6. After a while gvfs-dav times out. The attached patch solves my problem: It does not assume the message should be sent on the exact same connection as was tried previously.
I think this is exactly the same as https://bugzilla.gnome.org/show_bug.cgi?id=658814
*** Bug 658814 has been marked as a duplicate of this bug. ***
Could you check if the fix for #651146 fixes also your problem?
Attachment https://bugzilla.gnome.org/attachment.cgi?id=197743 does not fix my problem. I cannot apply https://bugzilla.gnome.org/attachment.cgi?id=193442 cleanly to my libsoup version 2.34.0.
(In reply to comment #4) > Attachment https://bugzilla.gnome.org/attachment.cgi?id=197743 does not fix my > problem. > I cannot apply https://bugzilla.gnome.org/attachment.cgi?id=193442 cleanly to > my libsoup version 2.34.0. You need both patches, otherwise it won't work.
No, 193442 is only needed for the test program, not for the bugfix itself. Pretty sure this is a different bug from that one. The problem here is that libsoup is noticing that the connection has been closed by the server (and so setting its state to DISCONNECTED), but it doesn't get removed from the SoupMessageQueueItem when it does that.
(In reply to comment #6) > No, 193442 is only needed for the test program, not for the bugfix itself. Yeah I was talking about the process of applying the patch, maybe there was some conflict.
ok, actually the patch in bug 651146 half-fixes this; instead of hanging, it now gets a "Connection terminated unexpectedly" error right away (but should work if you try it a second time).
fixed in master
I'm not entirely sure this fixes my issue: I tried with the following revision from libsoup: :~/projects/libsoup$ git log | head -1 commit f03674c2e9999781da756b7579eb3a3404e6f2a4 and compiled a custom gvfsd, verified that it uses the custom gvfsd-dav, and that gvfsd-dav is linked to the custom version of libsoup. Using this setup, I still get the bad behaviour as before. I attach two logs from running: GVFS_DEBUG=1 GVFS_HTTP_DEBUG=1 ./gvfsd --replace * One where I wait a few seconds before inputting the password (gvfs-libsoup-bad-debug.txt), which fails. * One where I hurry up (gvfs-libsoup-good-debug.txt), which succeeds. As you can see the bad one still tries to reuse the same socket. I verified that my patch still applies to git, but now it doesn't succeed in connecting anymore (see gvfs-libsoup-withpatch-debug.txt): it hangs in the last step, but it succeeds in authenticating and using a different socket. Is there any more information I can provide?
Created attachment 201939 [details] Waiting before giving password
Created attachment 201940 [details] Quickly giving password, succeeds.
Created attachment 201941 [details] New behaviour with patch, hangs.
(I used gvfs version 1.8.0, as this is the one shipped with my distro. I tried to set the bug status, to something reasonable, but I think that failed.)