GNOME Bugzilla – Bug 601525
e-calendar-factory crashes the second time I start evo
Last modified: 2013-09-14 16:53:56 UTC
I start evolution in mailer, and have selected a mail with a meeting invitation. I let it do until it's idle, (all the fetching from server and calendars and such) and close evolution. Then I run evolution again, pretty quickly, and the e-calendar-factory crashes in Thread 1 with backtrace shown below. I also noticed a runtime warning on console: exchange-mapi-connection.c:1335: Leaving exchange_mapi_connection_fetch_items: folder-id A9758C5D00000001 (process:11579): libedata-cal-CRITICAL **: e_data_cal_notify_mode: assertion `E_IS_DATA_CAL (cal)' failed but that might be unrelated to this issue, it might be because of the MAPI only. Note the patch from bug #597648 is not helping here, and seeing that only the dbus code is involved in the main thread of the process it's probably no surprise.
+ Trace 219007
Thread 1 (Thread 0x7ffff7732790 (LWP 11579))
At least in e-addressbook-factory, this seems to be a GSlice misuse by dbus-glib: ==10065== Invalid read of size 4 ==10065== at 0x4372B86: g_slice_alloc (gslice.c:474) ==10065== by 0x4378DE2: g_string_sized_new (gstring.c:380) ==10065== by 0x4173659: method_dir_signature_from_object_info (dbus-gobject.c:241) ==10065== by 0x4176315: object_registration_message (dbus-gobject.c:262) ==10065== by 0x41A6F12: ??? (in /lib/libdbus-1.so.3.4.0) ==10065== by 0x4199CEB: dbus_connection_dispatch (in /lib/libdbus-1.so.3.4.0) ==10065== by 0x4172BFC: message_queue_dispatch (dbus-gmain.c:101) ==10065== by 0x43549B7: g_main_context_dispatch (gmain.c:1960) ==10065== by 0x435825F: g_main_context_iterate (gmain.c:2591) ==10065== by 0x43586CE: g_main_loop_run (gmain.c:2799) ==10065== by 0x804A8B8: main (e-data-book-factory.c:484) ==10065== Address 0x2 is not stack'd, malloc'd or (recently) free'd ==10065== ==10065== ==10065== Process terminating with default action of signal 11 (SIGSEGV) ==10065== Access not within mapped region at address 0x2 ==10065== at 0x4372B86: g_slice_alloc (gslice.c:474) ==10065== by 0x4378DE2: g_string_sized_new (gstring.c:380) ==10065== by 0x4173659: method_dir_signature_from_object_info (dbus-gobject.c:241) ==10065== by 0x4176315: object_registration_message (dbus-gobject.c:262) ==10065== by 0x41A6F12: ??? (in /lib/libdbus-1.so.3.4.0) ==10065== by 0x4199CEB: dbus_connection_dispatch (in /lib/libdbus-1.so.3.4.0) ==10065== by 0x4172BFC: message_queue_dispatch (dbus-gmain.c:101) ==10065== by 0x43549B7: g_main_context_dispatch (gmain.c:1960) ==10065== by 0x435825F: g_main_context_iterate (gmain.c:2591) ==10065== by 0x43586CE: g_main_loop_run (gmain.c:2799) ==10065== by 0x804A8B8: main (e-data-book-factory.c:484) ==10065== If you believe this happened as a result of a stack ==10065== overflow in your program's main thread (unlikely but ==10065== possible), you can try to increase the size of the ==10065== main thread stack using the --main-stacksize= flag. ==10065== The main thread stack size used in this run was 8388608. ------------------------------- The above stack only happens when you run the factory with regular slice allocation -- if you run it with G_SLICE=always-malloc, it doesn't end up crashing.
Does it mean that the fix should go to dbus-glib?
Created attachment 149592 [details] [review] Don't double-free the list of connections (after it's already an invalid pointer) When the name owner of the addressbook factory on the D-Bus message bus changed, we were unreffing each of the books for a given connection, then freeing the GList that contained them. However, each unref caused the book's weak ref notify function to run, which itself modified the list, which could change the start of the list (and removed the link that contained that book anyhow). So in the end, we were holding onto a pointer which may or may not even point to a valid link in the list and then trying to free it.
Created attachment 149593 [details] [review] Fix the same crasher in the calendar (?) See the comment for attachment #149592 [details]
Milan, I just realized that this bug is for the calendar factory. The code is essentially identical, but I can't get the calendar factory to crash right now. Anyway, the patch for the addressbook factory definitely fixes an easily-repeatable crasher, and the second patch fixes the same problem for the calendar factory. Could you please review and try them out? Just let me know if anything needs to be changed and whether you'd like to apply them or have me do it.
I was thinking that it was one of the threading issues in dbus-glib and waited for the GDBus port. nice fix!!
Good. I tested this and both processes survive close and open of evolution. (Without patches they both crashed.) Please commit both to master.
Pushed to master.