GNOME Bugzilla – Bug 273375
[CRASH] Switching mail account server types causes Evolution to crash
Last modified: 2013-09-13 00:47:08 UTC
Description of Problem: Evolution 2.1.6 with GTK+ 2.6.4 crashes when changing the receiving mail server type. Selecting any option will crash Evo with a bus error. Steps to reproduce the problem: 1. Add a new email account 2. On the Receiving Email page of the wizard, try to select any server type Actual Results: Evo crashes with a bus error. Expected Results: Evo should not crash, but instead present options for the selected server type. How often does this happen? Every time with malloc scrubbing enabled. That is, FreeBSD allows one to "junk" fill unallocated for freed memory with 0xd0. This helps in weeding out usage of "bad" memory. I believe Linux offers a similar feature as well. If malloc scrubbing is not used, Evo does not crash. Additional Information: Here is the stack trace with debugging symbols. I was debating on whether or not file this against GTK+ since I wasn't sure if this was an Evo-only bug. However, I have been running with malloc scrubbing enabled for a while, and this has been the only thing to crash. Unfortunately, the best negative case I can come up with is that Evolution 2.0.4 with GTK+ 2.4.14 does not crash.
+ Trace 56446
this is the only thing i found using valgrind, and this is when the 'new account' window is closed: ==5048== Invalid write of size 4 ==5048== at 0x75FC9ACA: gtk_widget_destroyed (gtkwidget.c:1939) ==5048== by 0x763088C8: g_cclosure_marshal_VOID__VOID (gmarshal.c:77) ==5048== by 0x762F1C53: g_closure_invoke (gclosure.c:437) ==5048== by 0x76307ED0: signal_emit_unlocked_R (gsignal.c:2435) ==5048== by 0x76307088: g_signal_emit_valist (gsignal.c:2194) ==5048== by 0x763073D5: g_signal_emit (gsignal.c:2238) ==5048== by 0x75F0AB65: gtk_object_dispose (gtkobject.c:376) ==5048== by 0x75FD1A57: gtk_widget_dispose (gtkwidget.c:6386) ==5048== by 0x762F4C0E: g_object_run_dispose (gobject.c:602) ==5048== by 0x75F0AA18: gtk_object_destroy (gtkobject.c:361) ==5048== by 0x75FD264F: gtk_widget_destroy (gtkwidget.c:1913) ==5048== by 0x75E4636F: gtk_bin_forall (gtkbin.c:165) ==5048== by 0x75E7C1EA: gtk_container_foreach (gtkcontainer.c:1291) ==5048== by 0x75E7CACF: gtk_container_destroy (gtkcontainer.c:828) ==5048== by 0x763088C8: g_cclosure_marshal_VOID__VOID (gmarshal.c:77) ==5048== by 0x762F1F0D: g_type_class_meta_marshal (gclosure.c:514) ==5048== by 0x762F1C53: g_closure_invoke (gclosure.c:437) ==5048== by 0x763085AF: signal_emit_unlocked_R (gsignal.c:2551) ==5048== by 0x76307088: g_signal_emit_valist (gsignal.c:2194) ==5048== by 0x763073D5: g_signal_emit (gsignal.c:2238) ==5048== by 0x75F0AB65: gtk_object_dispose (gtkobject.c:376) ==5048== by 0x75FD1A57: gtk_widget_dispose (gtkwidget.c:6386) ==5048== by 0x762F4C0E: g_object_run_dispose (gobject.c:602) ==5048== by 0x75F0AA18: gtk_object_destroy (gtkobject.c:361) ==5048== Address 0x7C5404F4 is 20 bytes inside a block of size 32 free'd ==5048== at 0x7501ED79: free (vg_replace_malloc.c:127) ==5048== by 0x7635C9CF: g_free (gmem.c:188) ==5048== by 0x75092FC8: ep_finalise (e-config.c:135) ==5048== by 0x76EC1672: emp_finalise (em-config.c:91) ==5048== by 0x762F4A91: g_object_last_unref (gobject.c:570) ==5048== by 0x762F7CD5: g_object_unref (gobject.c:1590) ==5048== by 0x7509452C: ec_widget_destroy (e-config.c:797) ==5048== by 0x763088C8: g_cclosure_marshal_VOID__VOID (gmarshal.c:77) ==5048== by 0x762F1C53: g_closure_invoke (gclosure.c:437) ==5048== by 0x76307ED0: signal_emit_unlocked_R (gsignal.c:2435) ==5048== by 0x76307088: g_signal_emit_valist (gsignal.c:2194) ==5048== by 0x763073D5: g_signal_emit (gsignal.c:2238) ==5048== by 0x75F0AB65: gtk_object_dispose (gtkobject.c:376) ==5048== by 0x75FD1A57: gtk_widget_dispose (gtkwidget.c:6386) ==5048== by 0x762F4C0E: g_object_run_dispose (gobject.c:602) ==5048== by 0x75F0AA18: gtk_object_destroy (gtkobject.c:361) ==5048== by 0x75FD264F: gtk_widget_destroy (gtkwidget.c:1913) ==5048== by 0x75E4636F: gtk_bin_forall (gtkbin.c:165) ==5048== by 0x75E7C1EA: gtk_container_foreach (gtkcontainer.c:1291) ==5048== by 0x75E7CACF: gtk_container_destroy (gtkcontainer.c:828) ==5048== by 0x75FDAA41: gtk_window_destroy (gtkwindow.c:3524) ==5048== by 0x763088C8: g_cclosure_marshal_VOID__VOID (gmarshal.c:77) ==5048== by 0x762F1F0D: g_type_class_meta_marshal (gclosure.c:514) ==5048== by 0x762F1C53: g_closure_invoke (gclosure.c:437)
Created attachment 44973 [details] [review] fix for detectable bug
this should fix the bug i found ... but i dont know if it'll fix yours, i guess its worth a try though.
Tested it, but the same crash is still present.
i guess you don' have anything like valgrind on bsd to test with?
There is a relatively new port of valgrind to FreeBSD, but I'm not sure how well it works. I've never used valgrind. Where are instructions for using it with Evo? Thanks.
easiest is just to run it like: valgrind --num-callers=16 --alignment=8 --tool=addrcheck evolution-2.2 num-callers just makes the stack depth more useful. certain versions of valgrind don't work very well with evolution, so it may or may no work for you, but if it is possible to try it, its probably worth trying it.
Thanks. I played with two versions of valgrind on FreeBSD, and neither would even get Evo launched.
ok, thanks for trying anyway
Possible duplicate of bug# 272807 or http://bugzilla.ximian.com/show_bug.cgi?id=18830
pretty sure this is the same as 307794 *** This bug has been marked as a duplicate of 307794 ***
*** Bug 311917 has been marked as a duplicate of this bug. ***
*** Bug 307956 has been marked as a duplicate of this bug. ***