After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
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
Crash: libcamel-1.2: #0 camel_pstring_add (str=str@entry=0x4 <Address 0x4 ou...
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
3.4.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2012-08-22 06:40 UTC by Paul Menzel
Modified: 2015-08-12 13:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paul Menzel 2012-08-22 06:40:53 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.

Thread 1 (Thread 0xe9928b70 (LWP 10745))

  • #0 camel_pstring_add
    at camel-string-utils.c line 170
  • #1 camel_pstring_strdup
    at camel-string-utils.c line 251
  • #2 folder_summary_dupe_uids_to_array
    at camel-folder-summary.c line 1673
  • #3 g_hash_table_foreach
    at /build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./glib/ghash.c line 1524
  • #4 camel_folder_summary_get_array
    at camel-folder-summary.c line 1699
  • #5 maildir_summary_check
    at camel-maildir-summary.c line 579
  • #6 camel_local_summary_check
    at camel-local-summary.c line 285
  • #7 maildir_summary_sync
    at camel-maildir-summary.c line 743
  • #8 camel_local_summary_sync
    at camel-local-summary.c line 325
  • #9 local_folder_synchronize_sync
    at camel-local-folder.c line 429
  • #10 camel_folder_synchronize_sync
    at camel-folder.c line 4033
  • #11 sync_folder_exec
    at mail-ops.c line 1172
  • #12 mail_msg_proxy
    at mail-mt.c line 423
  • #13 g_thread_pool_thread_proxy
    at /build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./glib/gthreadpool.c line 309
  • #14 g_thread_proxy
    at /build/buildd-glib2.0_2.32.3-1-i386-987P8N/glib2.0-2.32.3/./glib/gthread.c line 801
  • #15 start_thread
    at pthread_create.c line 304
  • #16 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 130

Comment 1 Paul Menzel 2012-08-22 08:17:50 UTC
This is tracked as #685588 in Debian [1].

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685588
Comment 2 Milan Crha 2012-08-27 16:51:06 UTC
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.
Comment 3 Paul Menzel 2012-09-17 12:44:04 UTC
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.
Comment 4 Paul Menzel 2012-09-17 12:50:47 UTC
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.

Thread 1 (Thread 0xb547d890 (LWP 4182))

  • #0 camel_message_info_free
    at camel-folder-summary.c line 4386
  • #1 folder_free_message_info
    at camel-folder.c line 814
  • #2 camel_folder_free_message_info
    at camel-folder.c line 2385
  • #3 clear_info
    at message-list.c line 2975
  • #4 g_hash_table_foreach
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./glib/ghash.c line 1524
  • #5 clear_tree
    at message-list.c line 2995
  • #6 message_list_set_folder
    at message-list.c line 3874
  • #7 mail_reader_set_folder
    at e-mail-reader.c line 2907
  • #8 mail_paned_view_set_folder
    at e-mail-paned-view.c line 537
  • #9 e_mail_reader_set_folder
    at e-mail-reader.c line 4275
  • #10 mail_shell_view_got_folder_cb
    at e-mail-shell-view-private.c line 85
  • #11 g_simple_async_result_complete
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./gio/gsimpleasyncresult.c line 767
  • #12 complete_in_idle_cb_for_thread
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./gio/gsimpleasyncresult.c line 835
  • #13 g_idle_dispatch
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./glib/gmain.c line 4657
  • #14 g_main_dispatch
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./glib/gmain.c line 2539
  • #15 g_main_context_dispatch
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./glib/gmain.c line 3075
  • #16 g_main_context_iterate
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./glib/gmain.c line 3146
  • #17 g_main_loop_run
    at /build/buildd-glib2.0_2.33.12+really2.32.3-1-i386-RzMU9t/glib2.0-2.33.12+really2.32.3/./glib/gmain.c line 3340
  • #18 gtk_main
    at /build/buildd-gtk+3.0_3.4.2-3-i386-bj8mVg/gtk+3.0-3.4.2/./gtk/gtkmain.c line 1161
  • #19 main
    at main.c line 681

Comment 5 Milan Crha 2012-10-19 11:43:08 UTC
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.
Comment 6 Paul Menzel 2013-01-01 12:42:15 UTC
(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?
Comment 7 Milan Crha 2013-01-07 18:42:38 UTC
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.
Comment 8 Paul Menzel 2013-01-08 17:00:26 UTC
(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);
Comment 9 Milan Crha 2015-06-11 17:14:38 UTC
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?
Comment 10 Milan Crha 2015-08-12 13:45:41 UTC
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).