GNOME Bugzilla – Bug 757088
Hang when IMAP network connection is lost
Last modified: 2016-04-21 02:21:24 UTC
Geary master reliably hangs (i.e. 100% of the time) when connections to my Cyrus 2.4 server w/ StartTLS are lost without the server closing it. For whatever reason this seems to happen nearly all the time, so I find Geary hanging after a few minutes of inactivity 100% of the time after opening it. The problem seems to arise since src/mailer/main.vala enables graceful disconnects for IMAP endpoints by default, causing Geary.Endpoint.connect_async to enable graceful disconnects for GTcpConnection instances immediately after they have been opened. Thus, when the open connection dies GTcpConnection attempts a graceful disconnects but hangs waiting for data from the server. Here's the last relevant output when hang occurs with -d --log-deserializer enabled: > [deb] 23:01:05 101.254822 imap-deserializer.vala:809: [des:0011/GEARY_IMAP_DESERIALIZER_STATE_TAG] input error: Socket I/O timed out > [deb] 23:01:05 0.000021 imap-client-session.vala:1610: [000B/mail.quuxo.net/default:143 GEARY_IMAP_CLIENT_SESSION_STATE_AUTHORIZED] Receive failed: Socket I/O timed out > [deb] 23:01:05 0.000004 imap-client-session.vala:1323: [000B/mail.quuxo.net/default:143 GEARY_IMAP_CLIENT_SESSION_STATE_AUTHORIZED] Receive error, disconnecting: Socket I/O timed out > [deb] 23:01:05 0.000024 imap-deserializer.vala:250: [des:0011/GEARY_IMAP_DESERIALIZER_STATE_TAG] Waiting for deserializer to close... Nothing further is printed after this. This is the gdb stack trace at the same time:
+ Trace 235620
Note that a mainloop source is being destroyed and the connection is getting unref'ed, hence Geary isn't explicitly closing it, but because graceful shutdown was enabled for it this is attempted, but hangs because the connection is already down. This might be a GLib bug. A work-around is to avoid enabling graceful disconnects in Geary.Endpoint.connect_async, then in Geary.Imap.ClientConnection.disconnect_async enable graceful disconnect just before closing the GTcpConnection, but only if the stream reports itself as actually being open.
Possible GLib bug filed as Bug 757091.
Created attachment 314065 [details] Lazily enable graceful-disconnect Patch containing work-around for the problem.
Created attachment 314066 [details] [review] Lazily enable graceful-disconnect Patch containing work-around for the problem (this time flagged as a patch).
Note that GTcpConnection:graceful-disconnect is not useful for IMAP connections anyway, since it is already handled at the IMAP protocol level; the client sends LOGOUT and then waits for the OK response from the server.
See also Bug 765287.
Created attachment 326377 [details] [review] Remove the TCP graceful disconnect implementation. Since both IMAP and SMTP implement graceful disconnect at the application protocol level, doing it again at the TCP level is redundant. The use of graceful disconnect was introduced as part of the fix for Bug 713736, but it is not clear why it was included. Removing it also fixes Bug 757088, which can cause the UI to freeze if the connection is lost (e.g. on wifi drop out).
(In reply to Dan Winship from comment #4) > Note that GTcpConnection:graceful-disconnect is not useful for IMAP > connections anyway, since it is already handled at the IMAP protocol level; > the client sends LOGOUT and then waits for the OK response from the server. Yeah, good point - same for SMTP. Updated patch just removes it altogether. It might still be nice to fix the root cause of the freeze in Bug 757091.
Adam: I haven't run the updated patch much at all, but the effect is the same as the original patch, and I've been running that as part of my local build for the last 6 months with out any issue. I think it would be worth while committing.
Pushed to master. I've also seen this hang often, so it will be great news if this fixes it. Marking as fixed, optimistically.