GNOME Bugzilla – Bug 574940
Crash in message_info_to_db()
Last modified: 2013-08-23 18:07:16 UTC
Version: 2.26.x What were you doing when the application crashed? Waiting for emails to be downloaded/filtered (spam) Distribution: Gentoo Base System release 2.0.0 Gnome Release: 2.25.91 2009-03-01 (Gentoo) BugBuddy Version: 2.24.2 System: Linux 2.6.28 #134 SMP PREEMPT Sat Dec 27 13:16:10 EET 2008 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10503000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Compact Icon Theme: gnome Memory status: size: 900640768 vsize: 900640768 resident: 81223680 share: 24592384 rss: 81223680 rss_rlim: 18446744073709551615 CPU usage: start_time: 1236778601 rtime: 1946 utime: 1652 stime: 294 cutime:180 cstime: 125 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/evolution' [?1034h[Thread debugging using libthread_db enabled] [New Thread 0x7f7fb40c7750 (LWP 1793)] [New Thread 0x7f7f94aa1950 (LWP 2053)] [New Thread 0x7f7f8effd950 (LWP 2052)] [New Thread 0x7f7f981f4950 (LWP 1881)] 0x00007f7fb0e6455f in __libc_waitpid (pid=3184, stat_loc=0x7fffbc115bf0, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:41 in ../sysdeps/unix/sysv/linux/waitpid.c
+ Trace 213375
Thread 4 (Thread 0x7f7f981f4950 (LWP 1881))
Here's another stack trace in case you need it.
+ Trace 213686
Thread 1 (process 1129)
Any idea how to trigger this intentionally?
*** Bug 575828 has been marked as a duplicate of this bug. ***
*** Bug 576732 has been marked as a duplicate of this bug. ***
bug 576488 could also be a dupe
(In reply to comment #5) > bug 576488 could also be a dupe theoretically could be, say 98% chance. I guess the message info structure got freed before it should, and one message had tags (your bug) whereas the other not (this bug). Feel free to mark as a dupe.
*** Bug 576488 has been marked as a duplicate of this bug. ***
Not sure if it will help(In reply to comment #2) > Any idea how to trigger this intentionally? No idea from me. Here's another stacktrace in case it's useful:
+ Trace 214250
Thread 1 (process 6034)
(In reply to comment #8) > No idea from me. Here's another stacktrace in case it's useful: It's pretty same as the initial, only with newer sources (which is fine, line numbers match 2.26.0). Could you try to reproduce this with valgrind (I know, it's awfully slow with it), that might show something, hopefully. Say the command like this: $ valgrind --leak-check=full evolution &>evo-val.log
(In reply to comment #9) > > It's pretty same as the initial, only with newer sources (which is fine, line > numbers match 2.26.0). Could you try to reproduce this with valgrind (I know, > it's awfully slow with it), that might show something, hopefully. I'm afraid I can't. I use e-mail all day for my work. I can't be an effective worker with evolution being slowed down by valgrind, especially given the period of time it would take for that to reproduce given how many times I have hit it historically. I could be waiting a week or two, using evolution at valgrind speeds.
*** Bug 584419 has been marked as a duplicate of this bug. ***
Camel issue. Changing component to evolution-data-server.
Created attachment 135737 [details] valgrind log valgrind --leak-check=full evolution &>evo-val.log
See the attachment, I've succesfully got the crash again under valgrind. There is message about corrupted stack too from bug-buggy: Backtrace was generated from '/usr/lib/valgrind/x86-linux/memcheck' vgModuleLocal_do_syscall_for_client_WRK () at m_syswrap/syscall-x86-linux.S:115 in m_syswrap/syscall-x86-linux.S Current language: auto; currently asm
+ Trace 215804
Thanks for the valgrind traces. Pity it crashed in the most interesting part: >==8833== Thread 10: >==8833== Invalid read of size 4 >==8833== at 0x41EE742: message_info_to_db (camel-folder-summary.c:3262) >==8833== by 0x41EBD4E: save_to_db_cb (camel-folder-summary.c:1341) >==8833== by 0x54420EB: g_hash_table_foreach (ghash.c:1210) >==8833== by 0x41EB96C: save_message_infos_to_db (camel-folder- > summary.c:1398) >==8833== by 0x41EBA81: camel_folder_summary_save_to_db (camel-folder- > summary.c:1428) >==8833== by 0x41F3E3B: filter_free (camel-folder.c:2035) >==8833== by 0x4207ACD: session_thread_msg_free (camel-session.c:581) >==8833== by 0x7A09447: ms_thread_msg_free (mail-session.c:615) >==8833== by 0x42070ED: camel_session_thread_msg_free (camel-session.c:694) >==8833== by 0x4207A28: session_thread_proxy (camel-session.c:601) >==8833== by 0x547C5E5: g_thread_pool_thread_proxy (gthreadpool.c:265) >==8833== by 0x547AF7E: g_thread_create_proxy (gthread.c:635) >==8833== Address 0x1 is not stack'd, malloc'd or (recently) free'd >115 m_syswrap/syscall-x86-linux.S: No such file or directory. >Cannot access memory at address 0xb >==8833== Would you mind to try to run it once again, just do not lead it so far to the crash, but close evolution properly, "just before the crash"? Though it might not help much, I'm not sure now. Any idea how to debug this in a better way? -------------------------------------------------------------------------------- Created commit 69a1e92 in evo master, for the second chunk of invalid reads: ==8833== Thread 1: ==8833== Invalid read of size 1 ==8833== at 0x4026728: strlen (mc_replace_strmem.c:242) ==8833== by 0x54718CD: g_strdup (gstrfuncs.c:101) ==8833== by 0x79CBB78: emfv_list_message_selected (em-folder-view.c:2612) ==8833== by 0x79B99E4: emfb_gui_folder_changed (em-folder-browser.c:1937) ==8833== by 0x79FFBC2: do_async_event (mail-mt.c:681) ==8833== by 0x7A01B29: mail_msg_idle_cb (mail-mt.c:491) ==8833== by 0x544E940: g_idle_dispatch (gmain.c:3922) ==8833== by 0x5450847: g_main_context_dispatch (gmain.c:1814) ==8833== by 0x5453DAA: g_main_context_iterate (gmain.c:2448) ==8833== by 0x5454279: g_main_loop_run (gmain.c:2656) ==8833== by 0x4A99F02: bonobo_main (in /usr/lib/libbonobo-2.so.0.0.0) ==8833== by 0x805CEE2: main (main.c:704) ==8833== Address 0x9a5cc68 is 0 bytes inside a block of size 14 free'd ==8833== at 0x4024E3A: free (vg_replace_malloc.c:323) ==8833== by 0x5458CF5: g_free (gmem.c:190) ==8833== by 0x79B64C2: emfb_list_message_selected (em-folder-browser.c:1399) ==8833== by 0x53F1A3B: g_cclosure_marshal_VOID__STRING (gmarshal.c:496) ==8833== by 0x53E4B6A: g_closure_invoke (gclosure.c:767) ==8833== by 0x53F8D0E: signal_emit_unlocked_R (gsignal.c:3247) ==8833== by 0x53FA178: g_signal_emit_valist (gsignal.c:2980) ==8833== by 0x53FA5D5: g_signal_emit (gsignal.c:3037) ==8833== by 0x7A0F81A: message_list_select_uid (message-list.c:661) ==8833== by 0x79CCE53: emfv_set_message (em-folder-view.c:790) ==8833== by 0x79B99E4: emfb_gui_folder_changed (em-folder-browser.c:1937) ==8833== by 0x79FFBC2: do_async_event (mail-mt.c:681)
*** Bug 585782 has been marked as a duplicate of this bug. ***
*** Bug 588308 has been marked as a duplicate of this bug. ***
*** Bug 585932 has been marked as a duplicate of this bug. ***
Any progress on this? I'm seeing it quite a bit on 2.26.1 and the long startup time (i.e. many many minutes) of evolution, due to vfolder (lack of) scaling issues is making it painful.
*** Bug 592849 has been marked as a duplicate of this bug. ***
Any progress yet? Nobody answered my last query about status on this bug. Do queries just get ignored?
(In reply to comment #21) > Any progress yet? Nobody answered my last query about status on this bug. Do > queries just get ignored? Sort of ignored. As it's hard to reproduce, at least on my machine, then no progress done (yet). Some really good steps to reproduce this might help, but as I guess this is also data specific, then it became even harder.
(In reply to comment #22) > > Sort of ignored. As it's hard to reproduce, at least on my machine, then no > progress done (yet). Given that it happens here with some regularity, what could I help you with when it happens? > Some really good steps to reproduce this might help, Unfortunately, like a lot of evolution crashes, they just happen -- seemingly randomly (ok, not really randomly, I know). Sometimes when I'm not even doing anything with evolution. Hence, trying to cook up a reproducer is difficult. > but > as I guess this is also data specific, then it became even harder. Right. So what can I do for you when it happens? I can apply patches (to 2.26.x) to produce more debug info when it does happen if you want. I can poke around with gdb if you want. Just give me some steps and I'd be happy to help.
Created attachment 145110 [details] [review] test patch for evolution-data-server; (In reply to comment #23) > Right. So what can I do for you when it happens? I can apply patches (to > 2.26.x) to produce more debug info when it does happen if you want. Great. Let's try to hunt it. Please apply this test patch to evolution-data-server. It does nothing special, only makes evolution very chatty on a console. Please run evolution in a way: $ evolution &>evo.log and when you encounter this bug, see the history of the offending message info in the log. Its pointer is used in the message_info_to_db as an 'info' parameter, and is also printed on the console by this patch. Note that message infos are freed and created on demand, thus the same pointer can be used several times (aka the first pointer in the log is not necessary the one we are looking for). The log doesn't track when the info had been created, it tracks when it was used and freed, as I think this one was freed too early. Search folders, do you use?
(In reply to comment #24) > Created an attachment (id=145110) [details] > test patch > > for evolution-data-server; I'm afraid this patch makes evolution unusable. It spends too much time outputting the debug and the result is that the main UI goes AWOL for minutes at a time while it's spewing the debug. Just to provide an example of how chatty the output is: $ wc ~/tmp/evo.debug 4023740 12347510 188571606 /home/brian/tmp/evo.debug This was just from evo starting up (a few minutes), after which I had to abandon it due to the performance impact. > Search folders, do you use? Very heavily. Too heavily in fact for Evolution's ability to scale them, unfortunately.
Created attachment 145272 [details] test patch ][ for evolution-data-server; OK, this patch is with no debug output, I only added there one fix from 2.28 (the first chunk), and changed some reffing from search folders, which I noticed as probably missing while I was working on the previous patch. Please try running with this patch for few days, it'll either will work or will not.
(In reply to comment #26) > Created an attachment (id=145272) [details] > test patch ][ > > for evolution-data-server; > > OK, this patch is with no debug output, No, but in same manner as the debug patch, previously, this one just spews (and I mean really spews, to the point of tying up the UI waiting for the output on stderr) camel-CRITICAL errors: (evolution:5567): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:5567): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:5567): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:5567): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:5567): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:5567): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:5567): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:5567): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:5567): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:5567): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:5567): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:5567): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:5567): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:5567): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed
The patch from comment #26 shouldn't cause any such message, it isn't calling camel_object_ref, neither directly, nor indirectly. Please make sure you've applied only this patch and no other to your sources, and then try to find where these critical warnings are invoked from, the backtrace of it. If you can try even without the patch, then even better (just to be sure it's not caused by it). Thanks in advance. You can check all runtime warnings for example by this command: $ gdb evolution --ex "b g_logv" --ex r but I'm interested only on a backtrace of the first > camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed
(In reply to comment #28) > The patch from comment #26 shouldn't cause any such message, Well, you are the expert. All I can do is report the difference in experience here when I run without and with the patch. > Please make sure you've > applied only this patch and no other to your sources, Oh, most definitely. I am using dpkg-buildpackage to build this, which basically menas that my build environment is rigid and does the same thing for every build. > and then try to find > where these critical warnings are invoked from, the backtrace of it. If you can > try even without the patch, then even better (just to be sure it's not caused > by it). But without the patch, I don't get such messages. So let me try the patched version again and see if I can backtrace where the messages are coming from. > Thanks in advance. NP. Just to confirm, the only thing this patch is affecting is libcamel, right? > You can check all runtime warnings for example by this command: > $ gdb evolution --ex "b g_logv" --ex r Ahhh. Cool. > but I'm interested only on a backtrace of the first > > camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed Hrm. I seem to be getting a stream of: (evolution:17241): camel-WARNING **: Trying to check junk data is OBJECT 'CamelObject' (evolution:17241): camel-CRITICAL **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed (evolution:17241): camel-CRITICAL **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed and because the call to IA__g_logv only contains the format, but no meaningful context about what's going to be substituted into the format: Breakpoint 1, IA__g_logv (log_domain=0x5773e4 "camel", log_level=G_LOG_LEVEL_CRITICAL, format=0x62d0b6d "%s: assertion `%s' failed", args1=0xbfd6692c "\220�W") at /usr/src/glib2.0-2.20.1/glib/gmessages.c:395 I end up having to do a "where" before each one of these, "just in case" it's the one you are looking for (camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed). But I could end up going through hundreds if not thousands of these before I hit the assertion you are looking for. I think the breakpoint needs to be set back one step, where the call to IA__g_logv() is made, not at IA__g_logv(). Any idea where that is? I can go digging for it, but likely you will know where it is faster than I can dig it up.
OK. Found it. Not as easy as I was hoping though. What is interesting is the assertion you are looking for is one line above the assertion that is tripping constantly now: gboolean camel_object_is(CamelObject *o, CamelType ctype) { CamelObjectClass *k; g_return_val_if_fail(o != NULL, FALSE); g_return_val_if_fail(check_magic(o, ctype, CAMEL_OBJECT_MAGIC), FALSE); k = o->klass; while (k) { if (k == ctype) return TRUE; k = k->parent; } return FALSE; } The assertion that is tripping is the "g_return_val_if_fail(check_magic(o, ctype, CAMEL_OBJECT_MAGIC), FALSE);" not the one above it.
FWIW, all of those: (evolution:17241): camel-WARNING **: Trying to check junk data is OBJECT 'CamelObject' (evolution:17241): camel-CRITICAL **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed (evolution:17241): camel-CRITICAL **: camel_object_unref: assertion `CAMEL_IS_OBJECT(o)' failed are coming from evolution-rss. The unfortunate news is that when I was doing all of that debugging, I didn't have the libcamel with your patch installed. :-( So I've remedied that and now I am getting the: (evolution:1303): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed assertions again. The bad news is that I forgot to update the dbgsyms package for the new libcamel package, so I don't have detailed info in the stack trace from that assert:
+ Trace 218329
I wonder if I can load the new dbgsyms package and have gdb re-read that or if I have to restart this gdb once again.
Yay! Here it is, with full debugging symbols:
+ Trace 218330
And it's definitely very prolific! I can "continue" over and over again in this gdb and it just continues to hit the breakpoint over and over again. Unfortunately, I had to kill the evolution and gdb processes as they locked up my (gnome) desktop. I find that evolution can do that occasionally, i.e. when you strace it. Anyway, I hope those traces help.
Thanks for the update. I see I wasn't clear, what I really meant was to see the first camel (or evolution) runtime warning backtrace, as anything after that can be because of the first issue reported (in case the others are related to that one, but starting from top is easier that from bottom, in this case). The last trace looks very nice, let me look at it more closely.
I tried patched both 2.26.3 and 2.28.0 and I do not see this on any of those. What is your exact eds version, please? Also, line of camel-vee-summary.c:345 is pointing to > CAMEL_SUMMARY_UNLOCK(s, summary_lock); in my patched eds 2.26.3, which doesn't deal with camel_object_ref. Can you give me list of message_info_from_uid in camel-vee-summary.c and which line is 345, please? As I guess there were done some fixes meanwhile, so the best if you can move to 2.28. You mentioned evo-rss plugin, is it disabled now, together with its account(s)?
(In reply to comment #35) > I tried patched both 2.26.3 and 2.28.0 and I do not see this on any of those. > What is your exact eds version, please? 2.26.1 > Also, line of camel-vee-summary.c:345 is pointing to > > CAMEL_SUMMARY_UNLOCK(s, summary_lock); > in my patched eds 2.26.3, which doesn't deal with camel_object_ref. Can you > give me list of message_info_from_uid in camel-vee-summary.c 307: message_info_from_uid (CamelFolderSummary *s, const char *uid) 308: { 309: CamelMessageInfo *info; 310: 311: /* FIXME[disk-summary] too bad design. Need to peek it from cfs 312: * instead of hacking ugly like this */ 313: CAMEL_SUMMARY_LOCK(s, summary_lock); 314: 315: info = g_hash_table_lookup (s->loaded_infos, uid); 316: 317: if (info) 318: camel_message_info_ref (info); 319: 320: CAMEL_SUMMARY_UNLOCK(s, summary_lock); 321: 322: if (!info) { 323: CamelVeeMessageInfo *vinfo; 324: char tmphash[9]; 325: 326: /* This function isn't really nice. But no great way 327: * But in vfolder case, this may not be so bad, as vuid has the hash in first 8 bytes. 328: * So this just compares the entire string only if it belongs to the same folder. 329: * Otherwise, the first byte itself would return in strcmp, saving the CPU. 330: */ 331: if (!camel_folder_summary_check_uid (s, uid)) { 332: d(g_message ("Unable to find %s in the summary of %s", uid, s->folder->full_name)); 333: return NULL; 334: } 335: 336: /* Create the info and load it, its so easy. */ 337: info = camel_message_info_new (s); 338: camel_message_info_ref(info); 339: info->dirty = FALSE; 340: vinfo = (CamelVeeMessageInfo *) info; 341: info->uid = camel_pstring_strdup(uid); 342: strncpy(tmphash, uid, 8); 343: tmphash[8] = 0; 344: vinfo->summary = g_hash_table_lookup(((CamelVeeFolder *) s->folder)->hashes, tmphash); 345: camel_object_ref (vinfo->summary); 346: camel_folder_summary_insert (s, info, FALSE); 347: } 348: return info; 349: } Sorry about the loss of whitespace. Artifact of "while read line" loop to add line numbers. There is a utility to do this but I don't recall it's name. > and which line is > 345, please? As I guess there were done some fixes meanwhile, so the best if > you can move to 2.28. Not likely on Gnome 2.26, right? Probably too many dependencies on Gnome 2.28 components wouldn't you think? > You mentioned evo-rss plugin, is it disabled now, together with its account(s)? I had not disabled it, during my previous testing, no. I will disable evolution-rss and try again. (In reply to comment #34) > Thanks for the update. I see I wasn't clear, what I really meant was to see the > first camel (or evolution) runtime warning backtrace, OK. > as anything after that > can be because of the first issue reported (in case the others are related to > that one, but starting from top is easier that from bottom, in this case). Here's the first one:
+ Trace 218356
And that was all I could get due to evolution having locked up my gnome desktop again. I guess maybe I should try evolution without gdb now and see how well it works. Regardless, however. If the latest patch here and evolution-rss are incompatible and cause that spew of critical errors that I've seen previously, this is an unworkable situation as I am sure you might understand. So ultimately, if this patch fixes the problem it will need to be discovered why it causes so much trouble with evolution-rss.
Hrm. I spoke too soon. The terminal I started evolution from is being flooded with : (evolution:28578): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:28578): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:28578): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:28578): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:28578): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:28578): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:28578): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:28578): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:28578): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:28578): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:28578): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed (evolution:28578): camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed (evolution:28578): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed still. Granted, this seems to only happen a while after evolution has been running (with the patch in attachment 145272 [details]). Now my evolution process is very unresponsive and Xorg is pegging a CPU with the amount of output being displayed in that terminal. I'm going to have to back the patch out again so that evolution is again usable for me. Any instructions on how you want me to proceed next?
Most vee-folder issues with runtime warnings about camel_exception_get_id called with NULL had been fixed in this commit: http://git.gnome.org/cgit/evolution-data-server/commit/?id=495cb10 But not all, the last, containing imap_thaw call, is still there. Anyway, this particular runtime warning is not as that serious as the one about junk pointer or 'o != NULL'. (In reply to comment #36) > > and which line is > > 345, please? As I guess there were done some fixes meanwhile, so the best if > > you can move to 2.28. > > Not likely on Gnome 2.26, right? Probably too many dependencies on Gnome 2.28 > components wouldn't you think? Yeah, some dependencies there. Let's try with your 2.26.1, even it might take a long time. We can get rid of one issue (critical warning) after another. > I had not disabled it, during my previous testing, no. I will disable > evolution-rss and try again. > ... > Regardless, however. If the latest patch here and evolution-rss are > incompatible... I didn't mean it this way, I only wanted to try evo itself, and then with an add-on. Just a quick test, whether anything changes with evo-rss disabled. It probably will not change anything, thus you can leave it running. > And that was all I could get due to evolution having locked up my gnome > desktop again. I guess maybe I should try evolution without gdb now and > see how well it works. Actually, gdb locks X for me, killing gdb recovers it. I've no idea why it does that.
Created attachment 145778 [details] test patch ]I[ for evolution-data-server; Please revert the previous test patch and apply this new one. It should fix some warnings from console about "camel_object_is" assertions. It would be nice if you can also apply the patch from the above commit link (in previous comment), but I'm not sure whether it's applicable to 2.26.1 cleanly, as there had been some coding style and variable types changes which might reject the patch. If it'll claim, please apply the part from vee_add_folder function by hand, as that's the one which is claiming the most for you (based on your above traces). Thanks.
(In reply to comment #38) > Most vee-folder issues with runtime warnings about camel_exception_get_id > called with NULL had been fixed in this commit: > http://git.gnome.org/cgit/evolution-data-server/commit/?id=495cb10 I will try to apply that to my 2.26.1 if only to be able to run it with gdb, breaking on all messages and not having to plow through a few hundred other messages before getting to the one's really want to see. > (In reply to comment #36) > > I didn't mean it this way, I only wanted to try evo itself, and then with an > add-on. Yeah. I understood that. Sorry for implying otherwise. I am happy to temporarily disable evolution-rss just to make debugging of this other issue easier. > Just a quick test, whether anything changes with evo-rss disabled. It > probably will not change anything, thus you can leave it running. Well, it certainly did suppress one group of warnings, every time it refreshed it's feeds. > Actually, gdb locks X for me, killing gdb recovers it. I've no idea why it does > that. Yeah. Killing gdb releases my desktop as well. I would agree that it's locking X as well (rather than gnome) but the mouse still moves. Can't select or click anything, but it still moves.
(In reply to comment #40) > (In reply to comment #38) > > Most vee-folder issues with runtime warnings about camel_exception_get_id > > called with NULL had been fixed in this commit: > > http://git.gnome.org/cgit/evolution-data-server/commit/?id=495cb10 > > I will try to apply that to my 2.26.1 if only to be able to run it with gdb, > breaking on all messages and not having to plow through a few hundred other > messages before getting to the one's really want to see. You can also cheat the warning itself, go to eds/camel/camel-exception.c and comment out any g_warning you'll find there. It seems to be easier for our debugging. (I have there 3 g_warning calls.) Or if you have there these lines: > /* dont turn this off */ > #define w(x) x then turn it off, and that's it :) > #define w(x)
~sigh~ after several hours of pounding through gdb "continue" after "continue" because of all of the places where stupid debug prints are being done (i.e DEBUG: EI: mail_read_notify, bbdb: failed to get addressbook: e_book_new: no factories available for URI `', etc), it locked up my gnome desktop again. So hours of pain trying to use evo for no payoff. :-( I'm going to put a line of code where the assertion is happening so that I can break there instead of breaking at g_logv() which is just too painful to actually use evo long enough for this assertion to trip.
(In reply to comment #42) > ... I'm going to put a line of code where the assertion is happening... Oh, I see. Which function are we talking about? if it's camel_object_is, then I would recommend you to try this in camel-object.c:camel_object_is: if (!(o != NULL) || !(check_magic(o, ctype, CAMEL_OBJECT_MAGIC))) { printf ("bad pointer %p\n", o); } and put your breakpoint just on the line with the printf call. It helps me to run gdb on a text console, out of X, and attach to running evolution, but one loses context from evolution's console output with this, not talking about harder copy&paste of longer backtraces. Thank you for all the effort.
OK. I think I have it!
+ Trace 218429
(In reply to comment #43) > (In reply to comment #42) > > ... I'm going to put a line of code where the assertion is happening... > > Oh, I see. Which function are we talking about? if it's camel_object_is, then I > would recommend you to try this in camel-object.c:camel_object_is: > if (!(o != NULL) || !(check_magic(o, ctype, CAMEL_OBJECT_MAGIC))) { > printf ("bad pointer %p\n", o); > } Yeah. I used this patch: --- camel/camel-object.c 2009-10-19 12:17:47.000000000 -0400 +++ camel/camel-object.c.new 2009-10-19 12:16:18.000000000 -0400 @@ -860,6 +860,8 @@ { register CamelObject *o = vo; + if (!CAMEL_IS_OBJECT(o)) + fprintf(stderr, "woohoo! this is place 1 where we want to break!\n"); g_return_if_fail(CAMEL_IS_OBJECT(o)); REF_LOCK(); @@ -1018,6 +1020,8 @@ { CamelObjectClass *k; + if (!o) + fprintf(stderr, "woohoo! this is place 2 where we want to break!\n"); g_return_val_if_fail(o != NULL, FALSE); g_return_val_if_fail(check_magic(o, ctype, CAMEL_OBJECT_MAGIC), FALSE); and executed gdb with: -ex "b camel-object.c:864" \ -ex "b camel-object.c:1024" \ Of course, those two places are just one stack frame away from each other in the end so it's moot to do both, but what the heck, eh? :-) > It helps me to run gdb on a text console, out of X, Yeah. I did that too. > and attach to running > evolution, I started evolution from the gdb I ran on the text console (actually an ssh session in from another machine). Stole the running gnome environment variables from another process too. :-) > but one loses context from evolution's console output with this, not > talking about harder copy&paste of longer backtraces. Ahhh. Got that covered too. Here's my whole gdb: gdb $(which evolution) \ -ex "handle SIGPIPE pass nostop" \ -ex "set pagination off" \ -ex "set logging file ~/tmp/debug_evo.out" \ -ex "set logging on" \ -ex "b camel-object.c:864" \ -ex "b camel-object.c:1024" \ -ex r Along with setting the needed environment variables before calling gdb, it's quite a capable way to debug.
(In reply to comment #44) > OK. I think I have it! Hmm, this was supposed to be fixed with patch from comment #39, but you've it applied now, right?
(In reply to comment #39) > Created an attachment (id=145778) [details] > test patch ]I[ Could somebody, who has permissions to do so, fix the mime-type of this attachment?
(In reply to comment #46) > (In reply to comment #44) > > OK. I think I have it! > > Hmm, this was supposed to be fixed with patch from comment #39, but you've it > applied now, right? I most certainly had it applied when I produced the backtrace in comment #44 (I backed it out once I was done as the debug from it is just too copious), yes. I just verified it was applied, line by line, and also trying to un-apply it from the source pool I compiled in was successful.
Finally, with a little bit of hacking I seem to be able to reproduce all the warnings from console. I realized that my last change in message_info_from_uid about the folder hash is incorrect too. I'm investigating more.
Created attachment 145945 [details] test patch IV for evolution-data-server; this should calm down the error of camel-vee-summary.c: message_info_from_uid::camel_object_ref (vinfo->summary); The reason for me was that the unmatched folder had no idea about tracked folders, thus it couldn't find the related summary. I left in the patch also some debug outputs, just in case it'll be useful. Please give it a try. I hope it'll move us a step forward towards the crash itself. Thanks in advance.
OK. With patch IV applied, I seem to be getting another segfault fairly often (3 times this morning already):
+ Trace 218514
Thread 1 (process 9138)
I should add, that on this latest restart (after the above crash) I am seeing a duplication of the messages that were in folders prior to the crash (i.e. not messages that have arrived since restarting). That is, a good portion of messages are in my unread vfolder twice. If I delete one, they both get deleted. This is happening while evo is still scanning folders for changed messages. Perhaps when it's finally done and idle this will clear up.
The trace duplicate founder found two bugs, one is bug #555276 and the second is bug #567654. There are some test patches installed, maybe you have some of them already applied, please try and apply those which you do not have in your 2.26.1. Thanks in advance.
(In reply to comment #53) > The trace duplicate founder found two bugs, one is bug #555276 Both patches from this bug seem to do some checking and report: VFolder of VFolders not supporting. Ignoring loading this vfolder as a subfolder But I have a patch applied which gives me working vfolders of vfolders in my 2.26.1. I'd really like to avoid this regression once again. And besides, it looks like I already have the above patches (attachment 120715 [details] [review] at least) in my 2.26.1 source and the patch I have that enabled vfolders of vfolders simply voided the strcmp(..., "vfolder:/") checks by adding a "0 &&" to all three if statements as such: - if (strncmp((char *)l->data, "vfolder:/", 9) == 0 || - strncmp((char *)l->data, "email://vfolder@local", 21) == 0) { + if (0 &&(strncmp((char *)l->data, "vfolder:/", 9) == 0 || + strncmp((char *)l->data, "email://vfolder@local", 21) == 0)) { I'm afraid I don't recall which bug that patch came from. > and the second > is bug #567654. I already have this patch applied.
Is it crashing in a vfolder of vfolders only? You can check in gdb, just go to the frame where the camel_folder_get_message is called and command gdb: $(gdb) p folder->full_name You know, it seems we have fixed a crash in message_info_to_db, or it seems as so at least, and I'm not going to fix all vfolder bugs in this report, neither looking for all patches related to this on its way between 2.26.1 and 2.28.0 (maybe it's not many, maybe it is, I do not know). If you agree, then we can move with a new crasher to bug #567654 and try to solve it there. What do you think?
(In reply to comment #55) > Is it crashing in a vfolder of vfolders only? You can check in gdb, just go to > the frame where the camel_folder_get_message is called and command gdb: > $(gdb) p folder->full_name I think this is what you mean: (gdb) where
+ Trace 218525
No symbol "folder" in current context. (gdb) print m->folder->full_name $1 = 0x9ac7c80 "Unread mail" and indeed, "Unread mail" is a vfolder with vfolders in it. > You know, it seems we have fixed a crash in message_info_to_db, or it seems as > so at least, Or some other bug has been introduced which does not leave evolution running long enough to actually determine if the crash in message_info_to_db is gone or not now that I cannot run evolution for more than an hour or two before I get the above crash. Prior to applying attachment 145945 [details], evolution would/could run for days before crashing (usually in message_info_to_db). > and I'm not going to fix all vfolder bugs in this report, Indeed. No expectation that you will. > neither > looking for all patches related to this on its way between 2.26.1 and 2.28.0 > (maybe it's not many, maybe it is, I do not know). I'd be happy to just run 2.28 and see what's fixed (and what's newly broken, sadly) but the effort involved of upgrading all of the dependencies and their dependencies, etc. (i.e. upgrade to gnome 2.28 completely) is just more than I care to take on. I use distros for that. But my choice of distro, Ubuntu, is not at 2.28 (gnome or evo) in a stable release yet. > If you agree, then we can > move with a new crasher to bug #567654 and try to solve it there. What do you > think? Sure sounds good. I will paste my latest stack trace into that bug.
Hrm, either I added new bug or uncovered other, you've right. I agree with the update too, I'm also rather using distro's gnome, than compiling my own. What are your exact criteria for the "Unread mail" folder? Do you have there the "unread folder" check checked too (in a popup menu over the vfolder). I'm running a little debugging session, but I would like to have the closest setup as you have.
(In reply to comment #57) > Hrm, either I added new bug or uncovered other, you've right. I agree with the > update too, I'm also rather using distro's gnome, than compiling my own. Just no time for that kind of effort. :-( > What are your exact criteria for the "Unread mail" folder? Ahhh. You want to open that can of worms, huh? :-) > Do you have there > the "unread folder" check checked too (in a popup menu over the vfolder). Sure do. > I'm > running a little debugging session, but I would like to have the closest setup > as you have. I posted in another bug a "challenge" to the vfolder developer(s) to use a configuration similar to mine, to demonstrate the scalability issues. In that bug I described my configuration. Let me see if I can find it. Ahhh. Here it is. Bug 589245. To expand on that a bit, I have 2 IMAP accounts and a gmane account. In the gmane account, I have 32 newsgroups I subscribe to. To manage that many newsgroups (really, mailing lists) I create a few vfolders. One is called "active" which includes all of the gmane groups I actively read, daily, and one called "inactive" which contains the rest of the gmane groups. Every newly added gmane group must get added to one of those. I also create a volder which matches all unread messages in the "active" volder. I also have a vfolder which matches all my threads in the inactive vfolder. I also have a vfolder called "all" which basically just matches all messages in the active and inactive vfolders. I also have a vfolder which matches all my threads in the "all" gmane groups vfolder. But now that I look at it, the gmane groups vfolders are orthogonal to the "Unread mail" as none of those vfolders are included in the Unread mail vfolder. I do have another vfolder which encompasses all of my imap folders and gmane active but that's another story. As for the Unread mail vfolder, that is just the INBOX accounts from 3 IMAP accounts plus a couple of folders from those IMAP accounts. So, 5 IMAP folders all total, including the INBOXes from 3 IMAP accounts.
*** Bug 601802 has been marked as a duplicate of this bug. ***
(In reply to comment #59) > *** Bug 601802 has been marked as a duplicate of this bug. *** So given that the above bug was on 2.28, this bug has not gone away with that update. Can we continue to try to make progress with this?
(In reply to comment #60) > (In reply to comment #59) > > *** Bug 601802 has been marked as a duplicate of this bug. *** > > So given that the above bug was on 2.28, this bug has not gone away with that > update. Can we continue to try to make progress with this? Sure, just I'm kinda lost here, it's a bit longer, and it's also spread around in multiple bugs. Some of them probably caused (or uncovered) by the test patch IV. The question is: is the test patch IV doing anything better? If it's breaking your evo anyway, just somewhere else, then I agree it's hard to tell, but looking into changes there (ignoring those test prints), I think they are correct.
(In reply to comment #61) > > Sure, just I'm kinda lost here, it's a bit longer, and it's also spread around > in multiple bugs. Some of them probably caused (or uncovered) by the test patch > IV. The question is: is the test patch IV doing anything better? If it's > breaking your evo anyway, just somewhere else, then I agree it's hard to tell, > but looking into changes there (ignoring those test prints), I think they are > correct. Well, TBH, since upgrading to 2.28.1, I have not re-applied the test patch. I was hoping and praying that 2.28.1 fixed this one. Would you like me to apply attachment 145945 [details] to 2.28.1? Will it apply fairly cleanly (I can most certainly deal with a certain amount of fuzz but if the code structure has changed meaningfully, I won't be able to figure that out)?
Created attachment 147909 [details] test patch IV (for 2.28) for evolution-data-server; If you can, please apply this to evolution-data-server 2.28, the patch is basically the same, I only removed the chunk which is already part of 2.28 and updated the rest pieces for latest source. Thanks.
How is it working, or is not working, please?
Well, I don't seem to have had one of these crashes in a while now, so either: a) this patch has fixed it or b) other crashes are not letting evolution run long enough (I very rarely have evo run for even 24h before it crashes due to other bugs, mostly bug 600449 lately) to see this one. So, who knows. :-/
Created attachment 148337 [details] [review] eds patch for evolution-data-server; OK, thanks for the update. I believe the changes in a test patch IV are correct, thus I removed those debug prints (I hope you do not see them on the console any more too), and ended up with this patch, which I'm just about to commit and close this bug.
Created commit a09c5d5 in eds master (2.29.3+) Created commit 9d6e999 in eds gnome-2-28 (2.28.2+) Thanks for your help with this.
Hrm. Not so fast I don't think, sadly:
+ Trace 219403
Thread 26 (Thread 18885)
Thread 1 (Thread 18545)
Obviously this is with the patch in this bug applied.
Hrm. That "Unread mail", is it a virtual folder or a regular one? When it happens again, please give me the content of 'info' and 'record' from there, like: $(gdb) p *info $(gdb) p *record Also, the line it crashed on, is it this one in your sources too? >3409 tmp = g_string_new (NULL); >3410 if (mi->references) { >3411 g_string_append_printf (tmp, "%lu %lu %lu", (gulong)mi->mes... >3412 for (i=0;i<mi->references->size;i++)
(In reply to comment #69) > Hrm. That "Unread mail", is it a virtual folder or a regular one? Virtual. > When it > happens again, please give me the content of 'info' and 'record' from there, I still have the core file. Let me go grab them... > like: > $(gdb) p *info > $(gdb) p *record (gdb) p *info $1 = {summary = 0xb024b028, refcount = 4, uid = 0xa7d4f2f0 "7LYaX5mw355726", dirty = -1} (gdb) p *record Cannot access memory at address 0x0 > Also, the line it crashed on, is it this one in your sources too? > >3409 tmp = g_string_new (NULL); > >3410 if (mi->references) { > >3411 g_string_append_printf (tmp, "%lu %lu %lu", (gulong)mi->mes... > >3412 for (i=0;i<mi->references->size;i++) Yes, my sources match up exactly as above.
(In reply to comment #70) > (gdb) p *info > $1 = {summary = 0xb024b028, refcount = 4, uid = 0xa7d4f2f0 "7LYaX5mw355726", > dirty = -1} Good, so it should be alive. > (gdb) p *record > Cannot access memory at address 0x0 Strange, 'record' cannot be NULL in this place, it had been allocated and accessed many time before the line 3411. > > >3410 if (mi->references) { > > >3411 g_string_append_printf (tmp, "%lu %lu %lu", ... > Yes, my sources match up exactly as above. hmm, then something with references, it seems. please give me also mi->references, *mi, mi->references->size values.
(gdb) p mi->references Cannot access memory at address 0x3c (gdb) p *mi Cannot access memory at address 0x0 (gdb) p mi->references->size Cannot access memory at address 0x3c BTW: should we not reopen this bug?
(In reply to comment #72) > BTW: should we not reopen this bug? It seems so.
Hit again:
+ Trace 219482
Thread 1 (Thread 9871)
*** Bug 604239 has been marked as a duplicate of this bug. ***
*** Bug 604357 has been marked as a duplicate of this bug. ***
Still experiencing this one:
+ Trace 219690
Thread 24 (Thread 17205)
Thread 1 (Thread 16546)
Created attachment 150187 [details] test patch V for evolution-data-server; OK, I tried to look for calls of camel_message_info_free and similar and I'm not sure if I got all the places and understood actual things all around, but anyway, this is a test patch. It's for 2.29.4, but should be applicable to 2.28.x too, and as it's not so long, the worst by hand. Please give it a try. Thanks in advance. (Note, it may crash if I did a wrong change.)
(In reply to comment #78) > Created an attachment (id=150187) [details] > test patch V > > for evolution-data-server; camel/providers/local/camel-maildir-folder.c failed to patch. My source doesn't have a maildir_transfer_messages_to() function in it. The other files patched fine with this patch so I just removed the failing hunks out of: patching file camel/camel-folder-summary.c Hunk #1 succeeded at 2362 (offset 12 lines). Hunk #2 succeeded at 2378 (offset 12 lines). patching file camel/providers/local/camel-maildir-folder.c Hunk #1 FAILED at 408. Hunk #2 FAILED at 423. 2 out of 2 hunks FAILED -- saving rejects to file camel/providers/local/camel-maildir-folder.c.rej patching file camel/providers/local/camel-mbox-summary.c
(In reply to comment #79) > camel/providers/local/camel-maildir-folder.c failed to patch. My source > doesn't have a maildir_transfer_messages_to() function in it. Ah, OK, might be added to master recently, not in gnome-2-28 branch.
With the latest patch (attachment 150187 [details]) applied, I still got this:
+ Trace 219875
Thread 1 (Thread 26676)
(In reply to comment #81) > With the latest patch (attachment 150187 [details]) applied, I still got this: Hrm, OK, then I've not much idea on this, I'm sorry. Maybe when I would be able to reproduce it myself, to try deeper debugging, but doing it blindly obviously doesn't lead to anything. Thanks for testing it.
Here's another from this morning:
+ Trace 219878
Thread 1 (Thread 29988)
*** Bug 607701 has been marked as a duplicate of this bug. ***
Just wanted to update that I saw another of these this morning:
+ Trace 220217
Thread 1 (Thread 3221)
Still seeing this:
+ Trace 220334
Thread 24 (Thread 20527)
Thread 4 (Thread 10023)
Thread 1 (Thread 19682)
(In reply to comment #86) > Still seeing this: > What version of e-d-s are you using? If it's still 2.26.1, then please upgrade to either 2.26.3 or 2.28.2.
(In reply to comment #87) > (In reply to comment #86) > > Still seeing this: > > > > What version of e-d-s are you using? If it's still 2.26.1, then please upgrade > to either 2.26.3 or 2.28.2. Per comment #62 and the Version: tag on this bug, I am using 2.28(.1 to be exact). And I do have two bugs from this patch applied to my 2.28.1. Speaking of which, probably attachment 147909 [details] needs to be marked obsolete? Milan?
(In reply to comment #88) > And I do have two bugs from this patch applied to my 2.28.1. Speaking of > which, probably attachment 147909 [details] needs to be marked obsolete? Milan? Both are mutually exclusive, each of them is fixing other parts. Unfortunately none of them is fixing this bug report. I'm still looking for some steps how to reproduce it on my machine, to be able to investigate it properly. Maybe we can try to reiterate on some information, namely: a) what account type is this mostly causing (mbox, maildir, IMAP...) b) how is the account used (static account - no new mails, active account - receiving new mails by command/server/...; is it included in search folder(s)) c) what filter rules do you have? From the recent trace I only see that this happened at the end of filtering process, so it's some active account, with "Apply filters to new messages in Inbox" checked, so the rules might make the magic. Could you both share this information, together with (sanitized - without private information) ~/.evolution/mail/filters.xml and vfolders.xml files? I would like to look for the common parts there and try to reproduce it here. Speaking of the test patches, did your see any message on the console when the crash happened? I see that test patch IV is printing something there for some cases.
(In reply to comment #89) > > Both are mutually exclusive, each of them is fixing other parts. Mutually exclusive? That means that either could be applied but both should not be applied at the same time. That seems like a strange disposition for two patches. > Unfortunately > none of them is fixing this bug report. I'm still looking for some steps how to > reproduce it on my machine, to be able to investigate it properly. Unfortunately this never seems to be the direct result of action on my part. It just spontaneously happens. Most likely due to some configuration or environmental difference on my part. > Maybe we can try to reiterate on some information, namely: > a) what account type is this mostly causing (mbox, maildir, IMAP...) I only use IMAP (multiple) and NNTP account types. > b) how is the account used (static account - no new mails, active account - > receiving new mails All accounts receive new mails regularly. > by command/server/...; All are by server. > is it included in search folder(s)) All are included in at least one search folder. > c) what filter rules do you have? Many (17). > From the recent trace I only see that this > happened at the end of filtering process, so it's some active account, with > "Apply filters to new messages in Inbox" checked, so the rules might make the > magic. Interesting. > Could you both share this information, together with (sanitized - without > private information) ~/.evolution/mail/filters.xml and vfolders.xml files? I > would like to look for the common parts there and try to reproduce it here. OK. I will attach them. > Speaking of the test patches, did your see any message on the console when the > crash happened? I see that test patch IV is printing something there for some > cases. I will look next time.
Created attachment 152998 [details] sanitized filters.xml
Created attachment 152999 [details] sanitized vfolders.xml
(In reply to comment #90) > (In reply to comment #89) > > > > Both are mutually exclusive, each of them is fixing other parts. > > Mutually exclusive? That means that either could be applied but both should > not be applied at the same time. That seems like a strange disposition for > two patches. Ouch, right, I meant each of them is on its own, and they have nothing common. Never mind. I'm going to use your data to try to reproduce this. Thanks for it.
OK, I tried to reproduce this, but no luck, unfortunately. Next time it happens to you, please try to get values in a frame for filter_free at camel-folder.c:2015, for m->driver, m->recents, m->junk, m->notjunk and m->folder->full_name, though the only one having this run should be an IMAP Inbox. From watching your Message filters, I noticed there some rules which has no actions set. Is it same for you too, or did it happen during the sanitization of the file? You know, the UI doesn't allow you to create a rule without any action in them. maybe those got broken on some migration process between versions, hard to tell.
Created attachment 153838 [details] [review] eds patch ][ for evolution-data-server; just by an accident, while looking on another crasher, I realized that message_info_from_uid doesn't ref the message info always, but it should. I've no idea how much related it is to this issue, but for a bit it is, I believe. This patch includes also a little part from test patch V.
Created commit 4299e16 in eds master (2.29.91+) Created commit fcba67e in eds gnome-2-28 (2.28.3+) I'm not closing this yet, please try with the upcoming 2.28.3 (March 1st) or the development version and update if you'll see this with it. Thanks in advance.
(In reply to comment #94) > OK, I tried to reproduce this, but no luck, unfortunately. :-( > Next time it happens > to you, please try to get values in a frame for filter_free at > camel-folder.c:2015, for m->driver, m->recents, m->junk, m->notjunk and > m->folder->full_name, though the only one having this run should be an IMAP > Inbox. OK. Here's the stacktrace:
+ Trace 220595
Thread 1 (Thread 28179)
Cannot access memory at address 0x34 (gdb) print m->recents Cannot access memory at address 0x24 (gdb) print m->junk Cannot access memory at address 0x28 (gdb) print m->notjunk Cannot access memory at address 0x2c (gdb) print m->folder->full_name Cannot access memory at address 0x30 I suspect m is bad so: (gdb) print m $1 = <value optimized out> (gdb) print *m Cannot access memory at address 0x0 > From watching your Message filters, I noticed there some rules which has no > actions set. Yeah. 3 it seems. > You know, the UI doesn't allow you to create a rule without any > action in them. maybe those got broken on some migration process between > versions, hard to tell. Perhaps. (In reply to comment #95) > Created an attachment (id=153838) [details] [review] > edspatch ][ I will also try applying this one. I notice that the first two hunks of attachment 150187 [details] are included in "edspatch ][" but none of the rest of it is (and the two hunks to camel/providers/local/camel-maildir-folder.c doesn't even exist in my 2.28.1 source so I just removed from my patch from attachment 150187 [details]). Should I continue to apply the remainder of attachment 150187 [details] or leave it out altogether? Is there any harm in the rest or is it just extra debugging?
> I suspect m is bad so: > > (gdb) print m > $1 = <value optimized out> > (gdb) print *m > Cannot access memory at address 0x0 ah, bad, how I dislike the "<value optimized out>", I would suggest you to run configure like CFLAGS="-g -O0" ./configure ... to avoid optimizations on evolution-data-server, but it can have also impact on the executable behaviour, as the optimizations can change it. I do not know. > I notice that the first two hunks of attachment 150187 [details] are included in > "edspatch ][" ... yes, just remove the old one fully and use only the new one, from comment #95.
Thinking of the rest of the attachment 150187 [details], I believe changes there are correct and harmless, thus I committed it to master only as commit 2e90080. It's not exactly the same, there was missing one ..._free call in maildir.
Just hit this again:
+ Trace 220639
Thread 1 (Thread 15235)
This is still happening on gnome-2-28 as of 6b42bea5e3d80b2465f2ccd2af1c08ae5391d1ef:
+ Trace 220744
Thread 1 (Thread 22355)
Happened again. Are there any patches on this bug you would like me to be running on top of the gnome-2-28 branch or is the belief supposed to be that we are done here? Apparently we aren't:
+ Trace 220771
Thread 1 (Thread 10167)
(In reply to comment #102) > Happened again. Are there any patches on this bug you would like me to be > running on top of the gnome-2-28 branch or is the belief supposed to be that we > are done here? Apparently we aren't: You've right, we are not done with this issue (the bug is still opened). I'm just out of idea at the moment. The only thing I see is that the trouble happens on an "Unread mail" folder only, which we discussed above already.
*** Bug 613293 has been marked as a duplicate of this bug. ***
Just to keep things current, I've just experienced this one again:
+ Trace 221248
Thread 1 (Thread 19915)
And again here, using gnome-2-30 branch:
+ Trace 221950
Thread 21 (Thread 7411)
As this is 2.30.2, could somebody with permissions to do so, please update the Version: field?
*** Bug 619390 has been marked as a duplicate of this bug. ***
*** Bug 618080 has been marked as a duplicate of this bug. ***
*** Bug 619438 has been marked as a duplicate of this bug. ***
This bug is still alive and kicking in 2.30.x. Any chance of getting it fixed? Surely, it being simply bad data passed to strdup, the stack trace must be enough to fix it. I have a core file also if you need me to do any analysis on it.
+ Trace 222991
Thread 21 (Thread 15315)
Thread 1 (Thread 14689)
*** Bug 632198 has been marked as a duplicate of this bug. ***
And yet still alive on 2.30.3:
+ Trace 224394
Thread 1 (Thread 31382)
Any new ideas?
Wow. And another so quickly on the heels of the previous one:
+ Trace 224395
Thread 6 (Thread 22006)
Hrm. And another. Perhaps I have stumbled on to a method of being able to reproduce this somewhat reliably. I say somewhat because this is an operation I do frequently, but for whatever reason it's triggering this bug tonight. I'm simply marking a bunch of messages as Junk, which calls my "spamassassin" junk processor, which does take a number (10s perhaps, even) of seconds to process. So after I have clicked Junk and am waiting for my "spamassassin" (which is a custom script which does a bunch of things including but not limited to actually calling the real spamassassin script) to process the selected messages I go off and read (and perhaps reply) and (perhaps_ delete other messages.
+ Trace 224397
Thread 16 (Thread 28850)
Downstream bug report about the same (the initial issue) from 2.32.1: https://bugzilla.redhat.com/show_bug.cgi?id=657109
Closing as OBSOLETE since the stack trace is too old to be useful now. Reopen the bug and update the version field if this crash still occurs in Evolution 3.8 or later.