GNOME Bugzilla – Bug 570329
evolution crashed with SIGSEGV in strcmp, maildir_summary_sync
Last modified: 2012-10-25 08:28:59 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." ".
+ Trace 212164
Thread 5 (process 14964)
Thread 1 (process 23633)
Presumably camel_maildir_info_filename() returned NULL here. If that's a legitimate possibility then perhaps g_strcmp0() would be better.
*** Bug 570471 has been marked as a duplicate of this bug. ***
could be dupe of bug 560057
I think the hack would just avoid it, the last resort. Lemme see why it went null, in the first place.
*** Bug 579143 has been marked as a duplicate of this bug. ***
*** Bug 580118 has been marked as a duplicate of this bug. ***
Milan, will your patch from bug 571206 would help here ?
(In reply to comment #7) > Milan, will your patch from bug 571206 would help here ? I doubt it.
*** Bug 580575 has been marked as a duplicate of this bug. ***
*** Bug 581527 has been marked as a duplicate of this bug. ***
*** Bug 581442 has been marked as a duplicate of this bug. ***
*** Bug 583887 has been marked as a duplicate of this bug. ***
*** Bug 583965 has been marked as a duplicate of this bug. ***
*** Bug 584094 has been marked as a duplicate of this bug. ***
*** Bug 584108 has been marked as a duplicate of this bug. ***
*** Bug 584133 has been marked as a duplicate of this bug. ***
*** Bug 587206 has been marked as a duplicate of this bug. ***
*** Bug 588475 has been marked as a duplicate of this bug. ***
*** Bug 588519 has been marked as a duplicate of this bug. ***
*** Bug 588517 has been marked as a duplicate of this bug. ***
*** Bug 588650 has been marked as a duplicate of this bug. ***
*** Bug 588673 has been marked as a duplicate of this bug. ***
*** Bug 588701 has been marked as a duplicate of this bug. ***
*** Bug 588739 has been marked as a duplicate of this bug. ***
*** Bug 588780 has been marked as a duplicate of this bug. ***
*** Bug 588763 has been marked as a duplicate of this bug. ***
*** Bug 589279 has been marked as a duplicate of this bug. ***
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?
(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.
*** Bug 602415 has been marked as a duplicate of this bug. ***
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.
patch applied
*** Bug 604176 has been marked as a duplicate of this bug. ***
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.
Reid, did you have any chance to get an update on this, please?
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
(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:"?
(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???
(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.
(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.
(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??
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.
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.
uh. Reid, I think you were supposed to test the patch. Could you do that please?
(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.)
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
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. }
Created attachment 161666 [details] console trace file
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?
(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
Reid, ping, any update with respect to comment#49 ?
(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
(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.
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
(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.
(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
Hm Milan. So you patch didn't do anything then? ;-) Thank you, Reid, for testing.
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?
Does anybody still face this problem in 3.4 or 3.2?
(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.
Please reopen in case you'll see this in 3.4.x+. Thanks in advance.