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 570329 - evolution crashed with SIGSEGV in strcmp, maildir_summary_sync
evolution crashed with SIGSEGV in strcmp, maildir_summary_sync
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: Mailer
2.28.x (obsolete)
Other Linux
: High critical
: ---
Assigned To: Chenthill P
Evolution QA team
: 570471 579143 580118 580575 581442 581527 583887 583965 584094 584108 584133 587206 588475 588517 588519 588650 588673 588701 588739 588763 588780 589279 602415 604176 (view as bug list)
Depends on:
Blocks: 543389
 
 
Reported: 2009-02-03 09:20 UTC by Pedro Villavicencio
Modified: 2012-10-25 08:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
debug patch (1.76 KB, text/plain)
2009-12-08 15:13 UTC, Milan Crha
Details
debug patch ][ (2.85 KB, text/plain)
2010-03-31 15:28 UTC, Milan Crha
Details
console trace file (118.25 KB, text/plain)
2010-05-21 17:22 UTC, Reid Thompson
Details

Description Pedro Villavicencio 2009-02-03 09:20:01 UTC
this report has been filed here:

https://bugs.edge.launchpad.net/ubuntu/+source/evolution/+bug/323279

"Evolution was in the background when it crashed. I have 2 mail sources and a nntp server setup to check mail every 3 min. One of my mail sources is a IMAP pointing at gmail and the other is a local Maildir."

".

Thread 5 (process 14964)

  • #0 IA__g_datalist_id_get_data
    at /build/buildd/glib2.0-2.19.5/glib/gdataset.c line 436
  • #1 IA__g_param_spec_get_qdata
    at /build/buildd/glib2.0-2.19.5/gobject/gparam.c line 471
  • #2 IA__gtk_widget_style_get_valist
    at /build/buildd/gtk+2.0-2.15.0/gtk/gtkwidget.c line 9062
  • #3 IA__gtk_widget_style_get
    at /build/buildd/gtk+2.0-2.15.0/gtk/gtkwidget.c line 9100
  • #4 validate_row
    at /build/buildd/gtk+2.0-2.15.0/gtk/gtktreeview.c line 5602
  • #5 validate_visible_area
    at /build/buildd/gtk+2.0-2.15.0/gtk/gtktreeview.c line 5966
  • #6 do_presize_handler
    at /build/buildd/gtk+2.0-2.15.0/gtk/gtktreeview.c line 6279
  • #7 presize_handler_callback
    at /build/buildd/gtk+2.0-2.15.0/gtk/gtktreeview.c line 6301
  • #8 gdk_threads_dispatch
    at /build/buildd/gtk+2.0-2.15.0/gdk/gdk.c line 474
  • #9 IA__g_list_free_1
    at /build/buildd/glib2.0-2.19.5/glib/glist.c line 78
  • #10 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.19.5/glib/gmain.c line 1772
  • #11 g_main_context_iterate
    at /build/buildd/glib2.0-2.19.5/glib/gmain.c line 2454
  • #12 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.19.5/glib/gmain.c line 2633
  • #13 bonobo_main
    at bonobo-main.c line 311
  • #14 main
    at main.c line 690

Thread 1 (process 23633)

  • #0 strcmp
    from /lib/tls/i686/cmov/libc.so.6
  • #1 maildir_summary_sync
    at camel-maildir-summary.c line 770
  • #2 camel_local_summary_sync
    at camel-local-summary.c line 304
  • #3 local_sync
    at camel-local-folder.c line 515
  • #4 camel_folder_sync
    at camel-folder.c line 306
  • #5 vee_sync
    at camel-vee-folder.c line 589
  • #6 camel_folder_sync
    at camel-folder.c line 306
  • #7 refresh_folders_exec
    at mail-send-recv.c line 814
  • #8 mail_msg_proxy
    at mail-mt.c line 520
  • #9 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.19.5/glib/gthreadpool.c line 278
  • #10 IA__g_static_rec_mutex_lock
    at /build/buildd/glib2.0-2.19.5/glib/gthread.c line 301
  • #11 start_thread
    from /lib/tls/i686/cmov/libpthread.so.0
  • #12 clone
    from /lib/tls/i686/cmov/libc.so.6"

Comment 1 Matthew Barnes 2009-02-03 10:02:12 UTC
Presumably camel_maildir_info_filename() returned NULL here.  If that's a legitimate possibility then perhaps g_strcmp0() would be better.
Comment 2 Akhil Laddha 2009-02-05 03:59:38 UTC
*** Bug 570471 has been marked as a duplicate of this bug. ***
Comment 3 Akhil Laddha 2009-02-10 03:12:21 UTC
could be dupe of bug 560057
Comment 4 Srinivasa Ragavan 2009-02-10 12:15:59 UTC
I think the hack would just avoid it, the last resort. Lemme see why it went null, in the first place.
Comment 5 Akhil Laddha 2009-04-16 11:28:41 UTC
*** Bug 579143 has been marked as a duplicate of this bug. ***
Comment 6 Akhil Laddha 2009-04-27 04:48:22 UTC
*** Bug 580118 has been marked as a duplicate of this bug. ***
Comment 7 Akhil Laddha 2009-04-27 04:49:44 UTC
Milan, will your patch from bug 571206 would help here ? 
Comment 8 Milan Crha 2009-04-27 12:20:09 UTC
(In reply to comment #7)
> Milan, will your patch from bug 571206 would help here ? 

I doubt it.
Comment 9 palfrey 2009-04-28 15:57:45 UTC
*** Bug 580575 has been marked as a duplicate of this bug. ***
Comment 10 Fabio Durán Verdugo 2009-05-05 23:35:44 UTC
*** Bug 581527 has been marked as a duplicate of this bug. ***
Comment 11 Milan Crha 2009-05-21 16:48:08 UTC
*** Bug 581442 has been marked as a duplicate of this bug. ***
Comment 12 André Klapper 2009-05-26 15:59:05 UTC
*** Bug 583887 has been marked as a duplicate of this bug. ***
Comment 13 André Klapper 2009-05-27 15:31:15 UTC
*** Bug 583965 has been marked as a duplicate of this bug. ***
Comment 14 Fabio Durán Verdugo 2009-05-28 12:42:12 UTC
*** Bug 584094 has been marked as a duplicate of this bug. ***
Comment 15 Fabio Durán Verdugo 2009-05-28 12:44:12 UTC
*** Bug 584108 has been marked as a duplicate of this bug. ***
Comment 16 Fabio Durán Verdugo 2009-05-28 15:52:56 UTC
*** Bug 584133 has been marked as a duplicate of this bug. ***
Comment 17 Milan Crha 2009-06-29 08:58:58 UTC
*** Bug 587206 has been marked as a duplicate of this bug. ***
Comment 18 Akhil Laddha 2009-07-14 04:24:11 UTC
*** Bug 588475 has been marked as a duplicate of this bug. ***
Comment 19 palfrey 2009-07-14 15:36:57 UTC
*** Bug 588519 has been marked as a duplicate of this bug. ***
Comment 20 Akhil Laddha 2009-07-15 04:12:24 UTC
*** Bug 588517 has been marked as a duplicate of this bug. ***
Comment 21 Fabio Durán Verdugo 2009-07-15 13:37:27 UTC
*** Bug 588650 has been marked as a duplicate of this bug. ***
Comment 22 Akhil Laddha 2009-07-16 03:40:51 UTC
*** Bug 588673 has been marked as a duplicate of this bug. ***
Comment 23 Akhil Laddha 2009-07-16 03:41:00 UTC
*** Bug 588701 has been marked as a duplicate of this bug. ***
Comment 24 Akhil Laddha 2009-07-16 05:30:22 UTC
*** Bug 588739 has been marked as a duplicate of this bug. ***
Comment 25 Fabio Durán Verdugo 2009-07-16 16:55:39 UTC
*** Bug 588780 has been marked as a duplicate of this bug. ***
Comment 26 Fabio Durán Verdugo 2009-07-16 17:05:05 UTC
*** Bug 588763 has been marked as a duplicate of this bug. ***
Comment 27 Jens Falsmar Oechsler 2009-07-21 17:59:43 UTC
*** Bug 589279 has been marked as a duplicate of this bug. ***
Comment 28 Matt Lavin 2009-08-26 17:55:13 UTC
I got this same crash again today using the Evolution version packaged in Ubuntu Karmic

Version: 2.27.90-0ubuntu2

This time I had just applied a message filter a larger collection of messages that moved some mail to a new folder based on the Subject line.

This bug is listed as 'UNCONFIMRED', but there have been 23 dupes of it.  Is that right?
Comment 29 Akhil Laddha 2009-08-27 05:36:18 UTC
(In reply to comment #28)
> This bug is listed as 'UNCONFIMRED', but there have been 23 dupes of it.  Is
> that right?

Bug's state doesn't make any difference in getting a quick fix. I will raise the importance.
Comment 30 Fabio Durán Verdugo 2009-11-19 15:32:25 UTC
*** Bug 602415 has been marked as a duplicate of this bug. ***
Comment 31 Milan Crha 2009-12-08 15:13:45 UTC
Created attachment 149339 [details]
debug patch

for evolution-data-server;

hrm, I cannot reproduce this myself, and I'm afraid that the consequences how to trigger this are not that simple, but I have a debug patch and I would like to ask anybody here being able to compile evolution-data-server him/her-self to apply this patch and when evolution crashes check the output on console, whether the problematic message info had been freed before or not.

It is possible to put a workaround to the code, to not crash but skip the message info, or something like that, but it might result in strange behaviour, maybe even missing mails, thus I do not want to do that, but rather try to find the root of the issue. Though not being able to reproduce it myself makes it quite hard.
Comment 32 Reid Thompson 2009-12-08 17:22:44 UTC
patch applied
Comment 33 Reid Thompson 2009-12-09 14:09:19 UTC
*** Bug 604176 has been marked as a duplicate of this bug. ***
Comment 34 Milan Crha 2009-12-21 19:03:42 UTC
Thanks Reid. Did you see it any time recent? Could I ask you to try also patch from bug #574940 comment #78, as it changes little things in reference counting on message info's as well, thus might be related to this bug too? Though it can be also an evil, I do not know yet, it seemed to do something for my little testing, but testing in real usage would be completely different thing.
Comment 35 Milan Crha 2010-03-26 15:56:14 UTC
Reid, did you have any chance to get an update on this, please?
Comment 36 Reid Thompson 2010-03-26 16:14:40 UTC
it looks like the changes in patch from bug #574940 comment #78 are in git head?
I don't think i've had this problem since my last post
Comment 37 Milan Crha 2010-03-29 12:10:40 UTC
(In reply to comment #36)
> it looks like the changes in patch from bug #574940 comment #78 are in git
> head?

Correct, it's in now. Thinking of my change in the first chunk there, the 'found' may be rather a CamelMessageInfo and one should call free on that pointer, than on the 'info' parameter. But I can be wrong.

> I don't think i've had this problem since my last post

I'll keep it as it is for now, because you've it working fine. If you've still applied patch from comment #31 above, did you notice any prints on an evolution's console beginning with "message_info_free:" or "maildir_summary_sync:"?
Comment 38 Reid Thompson 2010-03-29 13:42:34 UTC
(In reply to comment #37)
> (In reply to comment #36)
> > it looks like the changes in patch from bug #574940 comment #78 are in git
> > head?
> 
> Correct, it's in now. Thinking of my change in the first chunk there, the
> 'found' may be rather a CamelMessageInfo and one should call free on that
> pointer, than on the 'info' parameter. But I can be wrong.
> 
> > I don't think i've had this problem since my last post
> 
> I'll keep it as it is for now, because you've it working fine. If you've still
> applied patch from comment #31 above, did you notice any prints on an
> evolution's console beginning with "message_info_free:" or
> "maildir_summary_sync:"?

I currently do not appear to have patch from comment #31 applied.  I can try to apply it if you want me to.  Looking at the patch, the two messages you note don't appear to be included in the debug output though???
Comment 39 Milan Crha 2010-03-29 15:12:15 UTC
(In reply to comment #38)
> I currently do not appear to have patch from comment #31 applied.  I can try to
> apply it if you want me to.

If you can apply it and try to run with it for few days, watching evolution's console log, then it'll be great.

> Looking at the patch, the two messages you note
> don't appear to be included in the debug output though???

I'm sorry, I do not follow here. The two messages are just printed on the evolution's console, whenever a condition for them is satisfied. You cannot turn off this printing, if you meant this.
Comment 40 Reid Thompson 2010-03-29 15:21:04 UTC
(In reply to comment #39)
> (In reply to comment #38)
> > I currently do not appear to have patch from comment #31 applied.  I can try to
> > apply it if you want me to.
> 
> If you can apply it and try to run with it for few days, watching evolution's
> console log, then it'll be great.
> 
> > Looking at the patch, the two messages you note
> > don't appear to be included in the debug output though???
> 
> I'm sorry, I do not follow here. The two messages are just printed on the
> evolution's console, whenever a condition for them is satisfied. You cannot
> turn off this printing, if you meant this.

Applying patch now against current git head.
Ignore my comment about debug output, error on my part in reading the patch.
Comment 41 Reid Thompson 2010-03-31 14:21:42 UTC
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #38)
> > > I currently do not appear to have patch from comment #31 applied.  I can try to
> > > apply it if you want me to.
> > 
> > If you can apply it and try to run with it for few days, watching evolution's
> > console log, then it'll be great.
> > 
> > > Looking at the patch, the two messages you note
> > > don't appear to be included in the debug output though???
> > 
> > I'm sorry, I do not follow here. The two messages are just printed on the
> > evolution's console, whenever a condition for them is satisfied. You cannot
> > turn off this printing, if you meant this.
> 
> Applying patch now against current git head.
> Ignore my comment about debug output, error on my part in reading the patch.

OK -- i've got logfiles with message_info_free: and maildir_summary_sync: output.  Would you like me to post them/email them to you/pastebin, etc??
Comment 42 Milan Crha 2010-03-31 14:28:08 UTC
If there are both, then yes, either e-mail them me (if it's long then no need to bother bugzilla) or put them here. Up to you. Thanks. I'll only try to check a pattern or some information from it and drop it.
Comment 43 Milan Crha 2010-03-31 15:28:26 UTC
Created attachment 157596 [details]
debug patch ][

for evolution-data-server;

Thanks for an update and email, it looks good. I unfortunately realized that I didn't add there enough information for better tracking. Could you apply this test patch instead of the previous, and unset CAMEL_DEBUG, so the log will contain only maildir printing, please?

I would like to also know, why is the print in message_info_free shown, and when, thus if you can try to get a backtrace of it (as a second step, I guess), then it'll be great. I'm not sure of your line numbers, but on actual eds master with this patch applied I would use:
   gdb evolution --ex "b camel-maildir-summary.c:346" --ex r --ex "t a a bt" --ex "d b 1" --ex c

which would show backtrace of the first occurrence of this printf.

Thanks a lot for the testing.
Comment 44 Tobias Mueller 2010-05-20 21:09:00 UTC
uh. Reid, I think you were supposed to test the patch. Could you do that please?
Comment 45 Reid Thompson 2010-05-21 04:17:57 UTC
(In reply to comment #44)
> uh. Reid, I think you were supposed to test the patch. Could you do that
> please?

Sorry -- sure. i can try.  It may be a futile effort for a while -- 

I'm currently experiencing regular coring (since the coring hasn't cleared up over the past several days, I'll try to post a trace for it tomorrow -- I may already have a bug representing it, will check and if so I'll just update it.)
Comment 46 Reid Thompson 2010-05-21 16:59:21 UTC
I applied the patch.  But am not getting very far due to the coring mentioned above (i did attach several more traces to bug 618035) -- Will keep trying and post an update if I get a backtrace of the printf
Comment 47 Reid Thompson 2010-05-21 17:20:48 UTC
here's console output up until coring.  There's a lot of output of maildir_summary_sync: messages.  I don't see any message_info_free messages.

With the current file.... the printf is at line 343, so I'm invoking with...
./evolution-env gdb ./evolution --ex "b camel-maildir-summary.c:343" --ex r --ex "t a a bt" --ex "d b 1" --ex c | tee eds-debug-trace.txt

334. extern gboolean maindir_in_sync;
335.
336. static void
337. message_info_free(CamelFolderSummary *s, CamelMessageInfo *mi)
338. {
339.    CamelMaildirMessageInfo *mdi = (CamelMaildirMessageInfo *)mi;
340.
341.    g_free(mdi->filename);
342.    if (maindir_in_sync) {
343.        printf ("   %s: %p freeing maildir mi (%s)\n", __FUNCTION__, mi, camel_message_info_uid (mi));
344.    }
345.
346.    ((CamelFolderSummaryClass *) camel_maildir_summary_parent_class)->message_info_free(s, mi);
347. }
Comment 48 Reid Thompson 2010-05-21 17:22:17 UTC
Created attachment 161666 [details]
console trace file
Comment 49 Milan Crha 2010-05-24 10:59:23 UTC
Thanks for the update, Reid. The last crash is slightly different, it is also done during maildir_summary_sync call, though this time when expunging the folder, not when just syncing it. And it didn't crash in strcmp, but it writing the index file for the summary, which failed for some reason. I agree these could be related. What is your evolution-data-server version/commit, please? Is it git master?
Comment 50 Reid Thompson 2010-05-24 12:38:04 UTC
(In reply to comment #49)
> What is your evolution-data-server version/commit, please? Is
> it git master?

Yes - git master.  I'm updating and rebuilding now to get the latest changes and 
debug info per
https://bugzilla.gnome.org/show_bug.cgi?id=618035#c4
Comment 51 Akhil Laddha 2010-07-10 04:24:02 UTC
Reid, ping, any update with respect to comment#49 ?
Comment 52 Reid Thompson 2010-07-13 15:34:10 UTC
(In reply to comment #51)
> Reid, ping, any update with respect to comment#49 ?

only the stack traces after comment#4 in 

https://bugzilla.gnome.org/show_bug.cgi?id=618035
Comment 53 Reid Thompson 2010-07-13 15:36:30 UTC
(In reply to comment #51)
> Reid, ping, any update with respect to comment#49 ?

Actually, i guess I should comment that it appears that i've not experienced this crash since May.
Comment 54 Milan Crha 2010-07-14 11:45:33 UTC
Reid, I suppose you've still the debug patch applied, right? because it can avoid the crash for some cases, and print a message on a console instead. The message should contain something like:
   maildir_summary_sync: no info at X for /some/path
Comment 55 Reid Thompson 2010-07-14 12:03:40 UTC
(In reply to comment #54)
> Reid, I suppose you've still the debug patch applied, right? because it can
> avoid the crash for some cases, and print a message on a console instead. The
> message should contain something like:
>    maildir_summary_sync: no info at X for /some/path

i'll have to go back and re apply the patches.  It may be a couple of days.  Last few attempts at building git head have been unsuccessful, waiting for that to clear up.
Comment 56 Reid Thompson 2010-08-02 14:17:25 UTC
(In reply to comment #55)
> (In reply to comment #54)
> > Reid, I suppose you've still the debug patch applied, right? because it can
> > avoid the crash for some cases, and print a message on a console instead. The
> > message should contain something like:
> >    maildir_summary_sync: no info at X for /some/path
> 
> i'll have to go back and re apply the patches.  It may be a couple of days. 
> Last few attempts at building git head have been unsuccessful, waiting for that
> to clear up.

re applied the patch last week.  have ran several days with it.  i've got almost 200MB of log files right now.  there's thousands of maildir_summary_sync entries, but NONE of the variant 'maildir_summary_sync: no info at X for /some/path'


$ ls -lh 2010*/evo.log.0 
-rw------- 1 rthompso staff 1.5M Jul 29 07:10 20100729.071005/evo.log.0
-rw------- 1 rthompso staff  55M Jul 30 10:14 20100729.071159/evo.log.0
-rw------- 1 rthompso staff  26M Jul 30 15:15 20100730.101440/evo.log.0
-rw------- 1 rthompso staff 109M Aug  2 09:25 20100730.142121/evo.log.0
-rw------- 1 rthompso staff 182K Aug  2 10:00 20100802.100020/evo.log.0
rthompso@raker>/opt/evo/log$ grep maildir_summary_syn 2010*/evo.log.0 |wc -l
422367
rthompso@raker>/opt/evo/log
$ grep maildir_summary_syn 2010*/evo.log.0 | grep info | wc -l
0
rthompso@raker>/opt/evo/log
Comment 57 Tobias Mueller 2010-08-04 23:28:37 UTC
Hm Milan. So you patch didn't do anything then? ;-)

Thank you, Reid, for testing.
Comment 58 Milan Crha 2010-08-23 14:44:43 UTC
Hrm, seems it didn't. Or the printf-s are causing "better timing".

Reid, is any file containing "without filename set" (quotes for clarity only), please?
Comment 59 André Klapper 2012-04-04 11:15:13 UTC
Does anybody still face this problem in 3.4 or 3.2?
Comment 60 Reid Thompson 2012-04-04 12:45:04 UTC
(In reply to comment #59)
> Does anybody still face this problem in 3.4 or 3.2?

I do not.  In either 3.2 or 3.4.
Comment 61 Milan Crha 2012-10-25 08:28:59 UTC
Please reopen in case you'll see this in 3.4.x+. Thanks in advance.