GNOME Bugzilla – Bug 682426
Crash: libcamel-1.2: #0 camel_pstring_add (str=str@entry=0x4 <Address 0x4 out of bounds>, own=own@entry=0) at camel-string-utils.c:170
Last modified: 2015-08-12 13:45:41 UTC
While composing a message Evolution 3.4.3 from Debian Sid/unstable crashed. $ dmesg […] [ 1775.978900] pool[10745]: segfault at 4 ip 00000000f6ab09c6 sp 00000000e9927e20 error 4 in libcamel-1.2.so.33.0.0[f6a03000+103000] Core was generated by `evolution --offline'. Program terminated with signal 11, Segmentation fault.
+ Trace 230720
Thread 1 (Thread 0xe9928b70 (LWP 10745))
This is tracked as #685588 in Debian [1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685588
Thanks for a bug report. Are you able to reproduce it on will? I didn't see it myself, and it seems to me like a maildir folder is updated, checked for changes, while it's left in an inconsistent state, with most likely freed UID in memory - something might free it.
No I cannot reproduce it at will. It just happened again, after I just sent (or while(?), at least after hitting Send) a message over IMAP. Though judging from your comment it is unrelated, what is done when the crash happens.
Looking at the backtrace it looks like, it happened somewhere else. Could you please advise if a separate report is needed. [ 7287.320716] evolution[4182]: segfault at 4 ip b69f9926 sp bf8fac20 error 4 in libcamel-1.2.so.33.0.0[b69b1000+103000] And here is the backtrace from the core dump. Program terminated with signal 11, Segmentation fault.
+ Trace 230861
Thread 1 (Thread 0xb547d890 (LWP 4182))
The backtrace from comment #4 should be fixed in 3.6.0+, there were issues when filling message list and playing with underlying message infos in the folder which was set in message list. I think I addressed it there already.
(In reply to comment #5) > The backtrace from comment #4 should be fixed in 3.6.0+, there were issues when > filling message list and playing with underlying message infos in the folder > which was set in message list. I think I addressed it there already. After spending over an hour finding such a commit, I could not find such a commit. Could you please point me to it?
Hmm, good question, though I do not recall which one I had on my mind 3 months ago. It looks like the memory leaks in message-list.c, the commit 84025c02ebe79b8477be and commit e5eb699ce36f57891cbe2, are those involved.
(In reply to comment #7) > Hmm, good question, though I do not recall which one I had on my mind 3 months > ago. It looks like the memory leaks in message-list.c, the commit > 84025c02ebe79b8477be and commit e5eb699ce36f57891cbe2, are those involved. Thank you. I had the first one applied already and still got occasional crashes (all in different place but related to invalid pointers or so). Backporting the second one to 3.4.4 I even get more crashes. Any idea why that might be? (I had not backported it before since I went backwards applying patches :(.) commit 646277ea5e9ad50ce280af6020186c0ae097de9d Author: Milan Crha <mcrha@redhat.com> Date: Wed Jun 27 20:17:28 2012 +0200 Fix few memory leaks Conflicts: mail/message-list.c diff --git a/mail/message-list.c b/mail/message-list.c index fe0106e..c4d447b 100644 --- a/mail/message-list.c +++ b/mail/message-list.c @@ -2665,12 +2665,16 @@ message_list_dispose (GObject *object) priv->destroyed = TRUE; - if (message_list->folder) { + if (message_list->folder) mail_regen_cancel (message_list); - if (message_list->uid_nodemap) - g_hash_table_foreach (message_list->uid_nodemap, (GHFunc) clear_info, message_list); + if (message_list->uid_nodemap) { + g_hash_table_foreach (message_list->uid_nodemap, (GHFunc) clear_info, message_list); + g_hash_table_destroy (message_list->uid_nodemap); + message_list->uid_nodemap = NULL; + } + if (message_list->folder) { g_signal_handlers_disconnect_by_func ( message_list->folder, folder_changed, message_list); g_object_unref (message_list->folder);
Oops, I see I forgot of you on this one. I'm sorry for that. I suppose you've this finally sorted out, especially with 3.12.x/3.16.x?
I'm closing this, considering it obsolete during the years. Feel free to reopen, if you find any steps with more recent version of the evolution(-data-server).