GNOME Bugzilla – Bug 573240
"no output stream" error when deleting emails and doing ctrl-e quickly
Last modified: 2013-06-20 14:01:53 UTC
* open a folder or an imap server * del del del del del del ctrl-e * sometimes is displays "no output stream" error
*** This bug has been marked as a duplicate of 573241 ***
*** Bug 573241 has been marked as a duplicate of this bug. ***
sorry for the duplicated bug, the isse is easy to trigger using del several time and then ctrl-e but happens on normal use too, deleted emails are listed as stricked there no sure that makes a difference
Created attachment 129554 [details] [review] proposed eds patch for evolution-data-server; try this please
the change seems to work great, no warning or error dialog when using it after several tries
Looks awesome to me. Did you see what broke it recently? or was it a inherent problem that we just saw?
Committed to trunk. Committed revision 10102. Based on changes in http://svn.gnome.org/viewvc/evolution-data-server/trunk/camel/providers/imap/camel-imap-command.c?view=log this is there even in a year 2005 (I didn't go later), so nothing new.
I'm reverting this patch for 2.26 because it causes serious IMAP regressions as well as potential summary database corruption. We'll need to rework this after branching. As the user cursors through message summaries, the IMAP connection eventually gets out of sync and Evolution begins failing to load message bodies. The error message reported in the preview pane is usually "Could not find message body in FETCH response", but I've also seen the IMAP provider get so confused that the error messages start showing raw IMAP responses from the server. When that happens, database corruption soon follows. After reverting this patch and letting Evolution rebuild my summary database, the message loading problems did not occur after nearly a full day's use. After restoring the patch the message loading problems resurfaced after only a few minutes of paging over the message list and purposefully cancelling slow loading messages. I'm taking heat about this from every corner of Red Hat, and the "IMAP stops working after awhile" bugs are already starting to trickle into Bugzilla. It might just be that we need to flush the stream when it's interrupted in lieu of disconnecting, or something simple like that. But this is a no go for 2.26; it needs further investigation and testing and we're days away from a hard code freeze. Patch reverted in revision 10143.
Bad, I wouldn't expect such breakage after this patch :(
Jeff Cai confirmed this in bug #574236. I think the root problem is we leave the input stream in an unknown state after an interrupt and can't reliably parse it thereafter. Hanging up and redialing (like a phone call) keeps us in a known state. If we're not gonna hang up, we might just need to wait for the server to stop talking (finish reading and then flush the stream) to get us back to a known state. Or there might be other got'chas, I don't know.
*** Bug 574733 has been marked as a duplicate of this bug. ***
Created attachment 130831 [details] test patch with debug messages for evolution-data-server; just a test patch, with new debug info prints, and only one relevant change (moving reconnect to start command from continuation command). It'll write on console whether you faced the issue, and if it'll not show in the UI anything wrong like before, and all the operations will succeed even on the server, then it should be file. Please try. Thanks a lot.
using the change and deleting and using ctrl-e several time leads quickly to "(evolution:17621): camel-WARNING **: camel_exception_get_id called with NULL parameter. camel_imap_store_readline: disconnect imap_command_start: disconnect imap_command_start: disconnect imap_command_start: disconnect camel_imap_store_readline: disconnect imap_command_start: not connected probably..." where the warning and not connected line are repeated a lot
it would be nice to know where exactly the camel-WARNING comes from, but for those other it's correct, it just monitors what it does. For example, in a version without patch, you should get the "no output stream" error after imap_command_start: not connected probably... but here is reconnects and continues happily forward. Does the UI/database/whatever indicates any issue like before (comment #8) while using the test patch?
the change seems to lead to crashes on error sometime "#0 0xb6838898 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
+ Trace 213591
(In reply to comment #15) > the change seems to lead to crashes on error sometime It doesn't crash, does it? > #6 0xb79df828 in camel_exception_get_id (ex=0x0) at camel-exception.c:238 > #7 0xb36ad42f in connect_to_server_wrapper (service=0x8ef8d10, ex=0x0) > at camel-imap-store.c:976 > #8 0xb36ad5b6 in imap_connect (service=0x8ef8d10, ex=0x0) here continues the interesting part, which I think leads up to imap_command_start? could you provide as long as possible backtrace of that output, except of lines above camel_exception_get_id, which are irrelevant (if it doesn't crash there, which I doubt).
it seems to be doing the same calls in loop copying some interations "#0 0xb69b3afe in _IO_default_xsputn () from /lib/tls/i686/cmov/libc.so.6
+ Trace 213601
I see, you've right, it crashes after some time on a stack overflow or something very similar.
Created attachment 131250 [details] test patch ][ for evolution-data-server; please give a try to this one, it's quite similar, only the stack cycle on disconnect is correctly managed, as in the other place where the LOGOUT is used. It'll write one more message about LOGOUT when you would be going to face the above issue again. I wasn't able to reproduce it myself, though.
*** Bug 577188 has been marked as a duplicate of this bug. ***
*** Bug 578193 has been marked as a duplicate of this bug. ***
Created attachment 132267 [details] [review] proposed eds patch ][ for evolution-data-server; stripped debug messages from the test patch ][
is bug 578827 related to this one ?
(In reply to comment #23) > is bug 578827 related to this one ? I think it isn't. It probably crashed in thread 2 in
+ Trace 214450
Thread 2 (process 1603)
No idea what that can do after hibernation.
Seb, does this patch work well for you?
is the change in 2.26.1? I was using the patch for some time without using but I'm using 2.26.1 now so if the change is not there it could need another round of testing on this version
I dont think the change is in 2.26.1. Probably, if it works well for you, we can include it in the upcoming release.
Sebastien, what's the status on this, please?
the bug didn't happen for a while not it seems to have been fixed in the 2.27 cycle...
not -> now, ie feel free to close the bug
OK, thanks for the update. I'm closing it, but feel free to reopen.
(In reply to comment #31) > OK, thanks for the update. I'm closing it, but feel free to reopen. Hrm, reopening per Andre's comment on IRC about "I'm seeing this on 2.28.0". Unfortunately I'm not much sure with a proposed patch, whether it has any side effects, thus some testing from anyone seeing this (often) will be very appreciated.
The old IMAP is gone in 3.8, replaced by IMAP+, which made this bug obsolete.
*** Bug 688620 has been marked as a duplicate of this bug. ***