GNOME Bugzilla – Bug 669082
Crash in imapx_command_copy_messages_step_done at camel-imapx-server.c:3325
Last modified: 2014-02-11 15:57:39 UTC
Evolution 3.3.5 Started evolution, message fetching and filtering were going on, evolution crashed in the middle somewhere. Program received signal SIGSEGV, Segmentation fault.
+ Trace 229567
Thread 2 (Thread 0xb5e42b70 (LWP 2115))
not sure if it's the same crash or different one Program received signal SIGSEGV, Segmentation fault.
+ Trace 229617
Thread 2 (Thread 0xb5e41b70 (LWP 2230))
Thread 1 (Thread 0xb611c890 (LWP 2226))
Evolution 3.5.2 (gwimap) (evolution:2028): camel-WARNING **: CamelStreamFs::close() set its GError but then reported success (evolution:2028): camel-WARNING **: Error message was: Error fetching message headers: UID FETCH (7204) Program received signal SIGSEGV, Segmentation fault.
+ Trace 230232
Thread 2776628080 (LWP 2055)
Similar downstream bug report from 3.2.3: https://bugzilla.redhat.com/show_bug.cgi?id=824262
And another one from 3.4.2: https://bugzilla.redhat.com/show_bug.cgi?id=832777
+ Trace 230381
Thread 1 (Thread 0x7f39abc5e700 (LWP 3144))
I just hit this with 3.4.3-2 (Fedora 17).
And now with 3.5.5.
Another downstream bug report from 3.6.1: https://bugzilla.redhat.com/show_bug.cgi?id=870709 Core was generated by `evolution'. Program terminated with signal 11, Segmentation fault.
+ Trace 231098
Thread 1 (Thread 0x7fdba0e9d700 (LWP 4376))
Created attachment 227881 [details] [review] Avoid the SEGV I get those crashes frequently with evolution 3.4.4 (Fedora 17). The attached patch prevents the SEGV, and with that I can now see the underlying cause, for example here: --- [imapx:A] Got continuation response for IDLE [imapx:A] ** Starting next command [imapx:A] * no, no jobs [imapx:A] camel_imapx_read: -1 [imapx:A] Caught exception in idle thread: I/O operation timed out [imapx:B] camel_imapx_read: buffer is '* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2008 Double Precision, Inc. See COPYING for distribution information. --- The mailbox in question is fairly big (a few 10k emails). With the patch evolution doesn't crash anymore, but still quite often has to re-fetch all emails. Note that checking ic->status happens in other functions as well, so this might be a valid improvement even though the cause of the issue isn't fixed: * imapx_command_select_done * imapx_command_append_message_done
Thanks for the patch. I'm fine with the workaround, it's better than crashing application. I left the bug opened, for the reasons you wrote in the above comment. Created commit 56e8972 in eds master (3.7.2+) Created commit 92b7365 in eds gnome-3-6 (3.6.2+)
I think the remaining issue has been handled. Closing.