GNOME Bugzilla – Bug 701138
Make e_cal_backend_sexp_match_comp() thread safe
Last modified: 2015-01-12 12:29:26 UTC
(evolution-calendar-factory:10570): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (evolution-calendar-factory:10570): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed Program received signal SIGSEGV, Segmentation fault.
+ Trace 231997
Thread 140736506865408 (LWP 12022)
$2 = (void *) 0x80008001f690 (gdb) x/40x mem 0x80008001f690: Cannot access memory at address 0x80008001f690
Can you get a backtrace on the first CRITICAL warning please?
That'll probably be this one... ==14773== Thread 11: ==14773== Invalid read of size 8 ==14773== at 0x337361425C: g_object_unref (gobject.c:2916) ==14773== by 0x3372A1482D: e_intervaltree_remove (e-cal-backend-intervaltree.c:652) ==14773== by 0x3372A14AEC: e_intervaltree_insert (e-cal-backend-intervaltree.c:504) ==14773== by 0x3372A1BB54: e_cal_backend_store_put_component_with_time_range (e-cal-backend-store.c:1201) ==14773== by 0xD696939: put_component_to_store (e-cal-backend-caldav.c:290) ==14773== by 0xD69D9CC: put_server_comp_to_cache (e-cal-backend-caldav.c:3156) ==14773== by 0xD69FE90: caldav_get_object (e-cal-backend-caldav.c:1609) ==14773== by 0x3372A17BB2: cal_backend_get_object (e-cal-backend-sync.c:617) ==14773== by 0x3372A1FE88: operation_thread (e-data-cal.c:521) ==14773== by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309) ==14773== by 0x376806C224: g_thread_proxy (gthread.c:798) ==14773== by 0x3909607C52: start_thread (pthread_create.c:308) ==14773== Address 0x13aa7750 is 0 bytes inside a block of size 376 free'd ==14773== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14773== by 0x376804DA4E: g_free (gmem.c:252) ==14773== by 0x3768063B0A: g_slice_free1 (gslice.c:1111) ==14773== by 0x337362FE68: g_type_free_instance (gtype.c:1962) ==14773== by 0x3372A1A9B4: cal_backend_store_internal_put_component (e-cal-backend-store.c:190) ==14773== by 0x3372A1B34C: cal_backend_store_put_component (e-cal-backend-store.c:698) ==14773== by 0x3372A1BB36: e_cal_backend_store_put_component_with_time_range (e-cal-backend-store.c:1200) ==14773== by 0xD696939: put_component_to_store (e-cal-backend-caldav.c:290) ==14773== by 0xD69D9CC: put_server_comp_to_cache (e-cal-backend-caldav.c:3156) ==14773== by 0xD69FE90: caldav_get_object (e-cal-backend-caldav.c:1609) ==14773== by 0x3372A17BB2: cal_backend_get_object (e-cal-backend-sync.c:617) ==14773== by 0x3372A1FE88: operation_thread (e-data-cal.c:521) ==14773== ==14773== Invalid read of size 8 ==14773== at 0x33736309D5: g_type_check_instance_is_a (gtype.c:3994) ==14773== by 0x3373614276: g_object_unref (gobject.c:2916) ==14773== by 0x3372A1482D: e_intervaltree_remove (e-cal-backend-intervaltree.c:652) ==14773== by 0x3372A14AEC: e_intervaltree_insert (e-cal-backend-intervaltree.c:504) ==14773== by 0x3372A1BB54: e_cal_backend_store_put_component_with_time_range (e-cal-backend-store.c:1201) ==14773== by 0xD696939: put_component_to_store (e-cal-backend-caldav.c:290) ==14773== by 0xD69D9CC: put_server_comp_to_cache (e-cal-backend-caldav.c:3156) ==14773== by 0xD69FE90: caldav_get_object (e-cal-backend-caldav.c:1609) ==14773== by 0x3372A17BB2: cal_backend_get_object (e-cal-backend-sync.c:617) ==14773== by 0x3372A1FE88: operation_thread (e-data-cal.c:521) ==14773== by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309) ==14773== by 0x376806C224: g_thread_proxy (gthread.c:798) ==14773== Address 0x13aa7750 is 0 bytes inside a block of size 376 free'd ==14773== at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14773== by 0x376804DA4E: g_free (gmem.c:252) ==14773== by 0x3768063B0A: g_slice_free1 (gslice.c:1111) ==14773== by 0x337362FE68: g_type_free_instance (gtype.c:1962) ==14773== by 0x3372A1A9B4: cal_backend_store_internal_put_component (e-cal-backend-store.c:190) ==14773== by 0x3372A1B34C: cal_backend_store_put_component (e-cal-backend-store.c:698) ==14773== by 0x3372A1BB36: e_cal_backend_store_put_component_with_time_range (e-cal-backend-store.c:1200) ==14773== by 0xD696939: put_component_to_store (e-cal-backend-caldav.c:290) ==14773== by 0xD69D9CC: put_server_comp_to_cache (e-cal-backend-caldav.c:3156) ==14773== by 0xD69FE90: caldav_get_object (e-cal-backend-caldav.c:1609) ==14773== by 0x3372A17BB2: cal_backend_get_object (e-cal-backend-sync.c:617) ==14773== by 0x3372A1FE88: operation_thread (e-data-cal.c:521) ==14773== (evolution-calendar-factory:14773): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
Valgrind even better, thanks!
Similar downstream bug report from 3.9.92: https://bugzilla.redhat.com/show_bug.cgi?id=1013213
I tried to reproduce this, also under valgrind, with purged local cache, but no luck, I cannot reproduce this. I'm wondering what cache and server state may trigger this.
I think I might have just hit this a few minutes ago, when the calendar factory spontaneously crashed. I have the core file if you want it (210M). Not going to dig into it myself right at the moment.
From my core file: Program terminated with signal 11, Segmentation fault.
+ Trace 232818
Not exactly the same as David's, but also crashing in EIntervalTree. Seems we have some thread-safety issues there.
I guess it's late to backup your local cache for that google calendar, right?
Downstream bug report about the same from 3.10.4: https://bugzilla.redhat.com/show_bug.cgi?id=1091567
+ Trace 233534
Thread 1 (Thread 0x7f73c27fc700 (LWP 23223))
Yet another similar crash from 3.12.5: https://bugzilla.redhat.com/show_bug.cgi?id=1134336 Core was generated by `/usr/libexec/evolution-calendar-factory'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 234039
Thread 1 (Thread 0x7fee1f7fe700 (LWP 2522))
*** Bug 736075 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > *** Bug 736075 has been marked as a duplicate of this bug. *** This shows a similar valgrind (stripped for interesting parts): > ==2944== Invalid read of size 8 > ... > ==2944== by 0x4E50084: e_intervaltree_insert (e-cal-backend-intervaltree.c:513) > ... > ==2944== by 0x195E9A6D: put_component_to_store (e-cal-backend-caldav.c:311) > ==2944== by 0x195F0C22: put_server_comp_to_cache (e-cal-backend-caldav.c:3236) > ... > ==2944== Address 0x31284c40 is 368 bytes inside a block of size 408 free'd > ... > ==2944== by 0x195F0C37: put_server_comp_to_cache (e-cal-backend-caldav.c:3249) > ... The e-cal-backend-caldav.c:3249 is: > g_object_unref (new_comp); where the 'new_comp' variable is a completely new ECalComponent. The e-cal-backend-caldav.c:3236 calls put_component_to_store() which bubbles down to cal_backend_store_internal_put_component() in e-cal-backend-store.c which at its end adds a new reference to the passed-in 'comp'. Also the EIntervalTree adds its reference to the 'comp' at e_intervaltree_insert(), thus the unref of 'new_comp' is legitimate. That might mean that not directly this part, but some other unrefs the new_comp incorrectly in certain case(s). Maybe. I miss a reliable reproducer which I would be able to use here and debug what exactly is happening in the background. Daniel mentioned it's happening to him with certain meeting invitations, which is a clue. It can be that the event is included in the calendar already, or has detached instances or anything like that. Or not. I do not know, I miss the reproducer so much.
In my case, yes it seems that the Exchange Server will automatically add a meeting invitation to the calendar before you've even seen the email, probably marked as something meaning not confirmed yet. That way someone else looking at your calendar can see that the time has already been requested. Just a hypothesis based on observed behavior. I also have a practice of copying the meeting to the Google Calendar. I haven't messed with the plugin that's supposed to do that for you yet. Anyway, that could create yet another possible duplicate meeting, as seen by Evolution.
The crash happened in the CalDAV calendar, thus the Google one in your case. As you can reproduce it with certain meeting invitations, could you check what he meeting looks like, both in the email and in the Google calendar, please? With the email side use View->Source (Ctrl+U), where will be a calendar attachment. Replace any private information with something else, like 'x'-es for each "censored" letter. With respect of the calendar, it's slightly worse, because in case of recurring meetings the event will be differently shown in UI (expanded recurrences) ad cannot be easily saved into the file. Saving whole Google calendar is impractical for privacy reasons, but maybe do it this way and take only those components which has the same UID (one component is surrounded by BEGIN:VEVENT and END:VEVENT lines). You can save whole calendar by right-clicking its name in the left tree and choosing "Save as", then pick iCalendar format.
(In reply to comment #14) > The crash happened in the CalDAV calendar, thus the Google one in your case. As > you can reproduce it with certain meeting invitations, could you check what he > meeting looks like, both in the email and in the Google calendar, please? AFAICS it's not about a specific calendar invitation - the calendar invitation email does not trigger the problem when opening it after a restart.
Finally had a few more issues that might shed some light on this (a crash included). I noticed many duplicate appointments in the Outlook calendar that appeared with an unprintable character (well, at least for my loaded fonts) as the meeting title. I deleted them. They turn out to be from the same day as three other Outlook meetings and one Google calendar meeting. However, the time was many hours early. I don't know if this is the same meeting corruption bug or not, but the reason for that is that it put them in the GMT time zone. And in fact I am often finding appointments that appear in GMT. Anyway I decided to kill evolution-calendar-factory and rerun with valgrind, and as soon as I started up Evolution the calendar factory crashed. But the traceback leading up to the crash is different this time. Also, after restarting evolution-calendar-factory and Evolution, it did not crash again. However, after converting a meeting to an appointment so that copying it to Google would not cause Google to send out meeting invites, then copying it to the Google Calendar, and finally converting another meeting to an appointment, valgrind spewed more memory violation reports. EDS version evolution-data-server-3.12.8-2.fc21.x86_64 Crash: ==11133== Invalid read of size 8 ==11133== at 0xAEACBA4: getenv (getenv.c:76) ==11133== by 0xAEA3141: guess_category_value (dcigettext.c:1356) ==11133== by 0xAEA3141: __dcigettext (dcigettext.c:561) ==11133== by 0x31986744: ??? (in /usr/lib64/gio/modules/libgiognutls.so) ==11133== by 0xC5D8771: g_input_stream_read (ginputstream.c:195) ==11133== by 0xC5D8771: g_input_stream_read (ginputstream.c:195) ==11133== by 0xC2F804E: soup_body_input_stream_read_raw (soup-body-input-stream.c:131) ==11133== by 0xC2F804E: soup_body_input_stream_read_chunked (soup-body-input-stream.c:183) ==11133== by 0xC2F804E: read_internal (soup-body-input-stream.c:250) ==11133== by 0xC5D8771: g_input_stream_read (ginputstream.c:195) ==11133== by 0xC3113E0: io_read (soup-message-io.c:646) ==11133== by 0xC311828: io_run_until (soup-message-io.c:864) ==11133== by 0xC312254: io_run (soup-message-io.c:936) ==11133== by 0xC30F044: soup_message_send_request (soup-message-client-io.c:161) ==11133== by 0xC320E5B: soup_session_process_queue_item (soup-session.c:1964) ==11133== Address 0x33700a68 is 296 bytes inside a block of size 408 free'd ==11133== at 0x4C2BB1C: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11133== by 0xAEACDAB: __add_to_environ (setenv.c:141) ==11133== by 0xAEACC50: putenv (putenv.c:78) ==11133== by 0x4C31027: putenv (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11133== by 0xB47DE1E: set_tz (icaltime.c:342) ==11133== by 0xB47EB09: icaltime_as_timet_with_zone (icaltime.c:435) ==11133== by 0x50A55B7: time_from_isodate (e-cal-time-util.c:656) ==11133== by 0x4E4EFC1: e_cal_backend_sexp_func_make_time (e-cal-backend-sexp.c:1392) ==11133== by 0x557C410: e_sexp_term_eval (e-sexp.c:783) ==11133== by 0x557C3E3: e_sexp_term_eval (e-sexp.c:779) ==11133== by 0x557CC6C: term_eval_and (e-sexp.c:287) ==11133== by 0x557C452: e_sexp_term_eval (e-sexp.c:771) ==11133== ==11133== Thread 6: ==11133== Invalid read of size 8 ==11133== at 0xC924EB5: g_type_check_instance_is_fundamentally_a (gtype.c:3979) ==11133== by 0xC9067C2: g_object_ref (gobject.c:3041) ==11133== by 0x4E4E485: e_intervaltree_search (e-cal-backend-intervaltree.c:707) ==11133== by 0x4E5456A: e_cal_backend_store_get_components_occuring_in_range (e-cal-backend-store.c:1475) ==11133== by 0x195E2247: caldav_start_view (e-cal-backend-caldav.c:4872) ==11133== by 0x4E5A8B3: calview_start_thread (e-data-cal-view.c:185) ==11133== by 0xCBB37B4: g_thread_proxy (gthread.c:764) ==11133== by 0xBAE0529: start_thread (pthread_create.c:310) ==11133== by 0xAF7477C: clone (clone.S:109) ==11133== Address 0x35854df0 is 368 bytes inside a block of size 408 free'd ==11133== at 0x4C2BB1C: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11133== by 0xAEACDAB: __add_to_environ (setenv.c:141) ==11133== by 0xAEACC50: putenv (putenv.c:78) ==11133== by 0x4C31027: putenv (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11133== by 0xB47DE1E: set_tz (icaltime.c:342) ==11133== by 0xB47EB09: icaltime_as_timet_with_zone (icaltime.c:435) ==11133== by 0x50A55B7: time_from_isodate (e-cal-time-util.c:656) ==11133== by 0x4E4EFC1: e_cal_backend_sexp_func_make_time (e-cal-backend-sexp.c:1392) ==11133== by 0x557C410: e_sexp_term_eval (e-sexp.c:783) ==11133== by 0x557C3E3: e_sexp_term_eval (e-sexp.c:779) ==11133== by 0x557CC6C: term_eval_and (e-sexp.c:287) ==11133== by 0x557C452: e_sexp_term_eval (e-sexp.c:771) ==11133== ==11133== Invalid read of size 1 ==11133== at 0xC924EDC: g_type_check_instance_is_fundamentally_a (gtype.c:3982) ==11133== by 0xC9067C2: g_object_ref (gobject.c:3041) ==11133== by 0x4E4E485: e_intervaltree_search (e-cal-backend-intervaltree.c:707) ==11133== by 0x4E5456A: e_cal_backend_store_get_components_occuring_in_range (e-cal-backend-store.c:1475) ==11133== by 0x195E2247: caldav_start_view (e-cal-backend-caldav.c:4872) ==11133== by 0x4E5A8B3: calview_start_thread (e-data-cal-view.c:185) ==11133== by 0xCBB37B4: g_thread_proxy (gthread.c:764) ==11133== by 0xBAE0529: start_thread (pthread_create.c:310) ==11133== by 0xAF7477C: clone (clone.S:109) ==11133== Address 0x49524f485455416c is not stack'd, malloc'd or (recently) free'd ==11133== ==11133== ==11133== Process terminating with default action of signal 11 (SIGSEGV) ==11133== General Protection Fault ==11133== at 0xC924EDC: g_type_check_instance_is_fundamentally_a (gtype.c:3982) ==11133== by 0xC9067C2: g_object_ref (gobject.c:3041) ==11133== by 0x4E4E485: e_intervaltree_search (e-cal-backend-intervaltree.c:707) ==11133== by 0x4E5456A: e_cal_backend_store_get_components_occuring_in_range (e-cal-backend-store.c:1475) ==11133== by 0x195E2247: caldav_start_view (e-cal-backend-caldav.c:4872) ==11133== by 0x4E5A8B3: calview_start_thread (e-data-cal-view.c:185) ==11133== by 0xCBB37B4: g_thread_proxy (gthread.c:764) ==11133== by 0xBAE0529: start_thread (pthread_create.c:310) ==11133== by 0xAF7477C: clone (clone.S:109) ==11133== Not a crash, but Valgrind still complained: ==11713== at 0x4C2CB82: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCBAB012: g_strdup (gstrfuncs.c:355) ==11713== by 0x24893FA4: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==11713== Address 0x338cfe00 is 0 bytes inside a block of size 153 free'd ==11713== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCB927FE: g_free (gmem.c:190) ==11713== by 0x2489131B: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0x248976C0: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== ==11713== Invalid read of size 1 ==11713== at 0x4C2CB94: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCBAB012: g_strdup (gstrfuncs.c:355) ==11713== by 0x24893FA4: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==11713== Address 0x338cfe01 is 1 bytes inside a block of size 153 free'd ==11713== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCB927FE: g_free (gmem.c:190) ==11713== by 0x2489131B: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0x248976C0: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== ==11713== Invalid read of size 8 ==11713== at 0x4C2E320: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCBAB02C: UnknownInlinedFun (string3.h:51) ==11713== by 0xCBAB02C: g_strdup (gstrfuncs.c:357) ==11713== by 0x24893FA4: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==11713== Address 0x338cfe00 is 0 bytes inside a block of size 153 free'd ==11713== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCB927FE: g_free (gmem.c:190) ==11713== by 0x2489131B: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0x248976C0: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== ==11713== Invalid read of size 8 ==11713== at 0x4C2E32E: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCBAB02C: UnknownInlinedFun (string3.h:51) ==11713== by 0xCBAB02C: g_strdup (gstrfuncs.c:357) ==11713== by 0x24893FA4: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==11713== Address 0x338cfe10 is 16 bytes inside a block of size 153 free'd ==11713== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCB927FE: g_free (gmem.c:190) ==11713== by 0x2489131B: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0x248976C0: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== ==11713== Invalid read of size 1 ==11713== at 0x4C2E3A0: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCBAB02C: UnknownInlinedFun (string3.h:51) ==11713== by 0xCBAB02C: g_strdup (gstrfuncs.c:357) ==11713== by 0x24893FA4: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==11713== Address 0x338cfe98 is 152 bytes inside a block of size 153 free'd ==11713== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCB927FE: g_free (gmem.c:190) ==11713== by 0x2489131B: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0x248976C0: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== ==11713== Invalid free() / delete / delete[] / realloc() ==11713== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCB927FE: g_free (gmem.c:190) ==11713== by 0x2489131B: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0x24893E83: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==11713== Address 0x338cfe00 is 0 bytes inside a block of size 153 free'd ==11713== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11713== by 0xCB927FE: g_free (gmem.c:190) ==11713== by 0x2489131B: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0x248976C0: ??? (in /usr/lib64/evolution-data-server/calendar-backends/libecalbackendews.so) ==11713== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==11713== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==11713== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==11713== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==11713== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==11713== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==11713== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==11713== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==11713== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2)
Thanks for the update. The genenv/putenv issue will be a problem. It's sort of known to cause trouble when these two interleave, but there is no thread safety being done on these functions (in the library which provides these functions). The interleave caught by valgrind happened in tow separate and independent libraries, which cannot "synchronize" between them self by any means. The second part comes from evolution-ews. Valgrind identified an issue, which would cause a crash otherwise, but you do not have installed debuginfo for evolution-ews, thus it's hard to tell where exactly the invalid g_free() was called (it's used many many many times in the code). This usually happens when an update of a local calendar cache is required, thus on start. It may be good to have a copy of ~/.cache/evolution/calendar/ to be able to easily reproduce it. My remote calendars do not change that often, unfortunately.
I've just got the getenv/putenv crash too, on Fedora 21, and it led me to: https://github.com/libical/libical/issues/86 I think I have a patch for it, to libical, to avoid putenv() completely. If the crash was caused by this, then we are almost there.
I installed evolution-ews-debuginfo and evolution-debuginfo for good measure. Also, I can reproduce the traceback at will if I try to convert an Outlook meeting to an appointment. Here's the new traceback with all the debuginfo: ==10835== Invalid read of size 1 ==10835== at 0x4C2CB82: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCBAB012: g_strdup (gstrfuncs.c:355) ==10835== by 0x24893FA4: ews_cal_modify_object_cb (e-cal-backend-ews.c:1813) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==10835== Address 0x3cf20ee0 is 0 bytes inside a block of size 153 free'd ==10835== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCB927FE: g_free (gmem.c:190) ==10835== by 0x2489131B: e_cal_backend_ews_async_data_free (e-cal-backend-ews.c:342) ==10835== by 0x248976C0: ews_create_attachments_cb (e-cal-backend-ews.c:1395) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== ==10835== Invalid read of size 1 ==10835== at 0x4C2CB94: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCBAB012: g_strdup (gstrfuncs.c:355) ==10835== by 0x24893FA4: ews_cal_modify_object_cb (e-cal-backend-ews.c:1813) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==10835== Address 0x3cf20ee1 is 1 bytes inside a block of size 153 free'd ==10835== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCB927FE: g_free (gmem.c:190) ==10835== by 0x2489131B: e_cal_backend_ews_async_data_free (e-cal-backend-ews.c:342) ==10835== by 0x248976C0: ews_create_attachments_cb (e-cal-backend-ews.c:1395) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== ==10835== Invalid read of size 8 ==10835== at 0x4C2E320: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCBAB02C: UnknownInlinedFun (string3.h:51) ==10835== by 0xCBAB02C: g_strdup (gstrfuncs.c:357) ==10835== by 0x24893FA4: ews_cal_modify_object_cb (e-cal-backend-ews.c:1813) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==10835== Address 0x3cf20ee0 is 0 bytes inside a block of size 153 free'd ==10835== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCB927FE: g_free (gmem.c:190) ==10835== by 0x2489131B: e_cal_backend_ews_async_data_free (e-cal-backend-ews.c:342) ==10835== by 0x248976C0: ews_create_attachments_cb (e-cal-backend-ews.c:1395) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== ==10835== Invalid read of size 8 ==10835== at 0x4C2E32E: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCBAB02C: UnknownInlinedFun (string3.h:51) ==10835== by 0xCBAB02C: g_strdup (gstrfuncs.c:357) ==10835== by 0x24893FA4: ews_cal_modify_object_cb (e-cal-backend-ews.c:1813) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==10835== Address 0x3cf20ef0 is 16 bytes inside a block of size 153 free'd ==10835== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCB927FE: g_free (gmem.c:190) ==10835== by 0x2489131B: e_cal_backend_ews_async_data_free (e-cal-backend-ews.c:342) ==10835== by 0x248976C0: ews_create_attachments_cb (e-cal-backend-ews.c:1395) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== ==10835== Invalid read of size 1 ==10835== at 0x4C2E3A0: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCBAB02C: UnknownInlinedFun (string3.h:51) ==10835== by 0xCBAB02C: g_strdup (gstrfuncs.c:357) ==10835== by 0x24893FA4: ews_cal_modify_object_cb (e-cal-backend-ews.c:1813) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xC9029AB: g_cclosure_marshal_generic_va (gclosure.c:1541) ==10835== Address 0x3cf20f78 is 152 bytes inside a block of size 153 free'd ==10835== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCB927FE: g_free (gmem.c:190) ==10835== by 0x2489131B: e_cal_backend_ews_async_data_free (e-cal-backend-ews.c:342) ==10835== by 0x248976C0: ews_create_attachments_cb (e-cal-backend-ews.c:1395) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== ==10835== Invalid free() / delete / delete[] / realloc() ==10835== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCB927FE: g_free (gmem.c:190) ==10835== by 0x2489131B: e_cal_backend_ews_async_data_free (e-cal-backend-ews.c:342) ==10835== by 0x24893E83: ews_cal_modify_object_cb (e-cal-backend-ews.c:1822) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== Address 0x3cf20ee0 is 0 bytes inside a block of size 153 free'd ==10835== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10835== by 0xCB927FE: g_free (gmem.c:190) ==10835== by 0x2489131B: e_cal_backend_ews_async_data_free (e-cal-backend-ews.c:342) ==10835== by 0x248976C0: ews_create_attachments_cb (e-cal-backend-ews.c:1395) ==10835== by 0xC5ED806: g_simple_async_result_complete (gsimpleasyncresult.c:763) ==10835== by 0xC5ED868: complete_in_idle_cb (gsimpleasyncresult.c:775) ==10835== by 0xCB8CAEA: g_main_dispatch (gmain.c:3111) ==10835== by 0xCB8CAEA: g_main_context_dispatch (gmain.c:3710) ==10835== by 0xCB8CE87: g_main_context_iterate.isra.29 (gmain.c:3781) ==10835== by 0xCB8D1B1: g_main_loop_run (gmain.c:3975) ==10835== by 0x52E95E1: dbus_server_run_server (e-dbus-server.c:230) ==10835== by 0xDD9CD5F: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==10835== by 0xDD9C7D0: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==10835== In addition, when I shut down Evolution, I got: The ECalBackendEws instance for "Notes" is shutting down. The ECalBackendFileJournal instance for "Personal" is shutting down. Entity: line 1: parser error : Extra content at the end of the document off time 0 ms.</t:Value></t:MessageXml></detail></s:Fault></s:Body></s:Envelope>
It's when everything looks fine. EIntervalTree adds its reference, ECalBackendStore adds its reference, even the e_cal_backend_sexp_match_comp() adds its reference and all of them removes the reference when needed. Except one little detail, the e_cal_backend_sexp_match_comp() can be called from multiple threads at once. That means, a reference is added to component A, but it is removed on component B, not talking that the ongoing check has changed the component itself during the processing. This issue, together with that libicals, are causing this crash. (Let's continue at bug #736006, if there will be anything to continue with, because I think this change and the libical change will fix that bug as well.I have test builds for fedora 21, to which I'll give links there). Created commit 243caac in eds master (3.13.9+) [1] Created commit cb54f20 in eds evolution-data-server-3-12 (3.12.9+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=243caac
(In reply to comment #19) > I installed evolution-ews-debuginfo and evolution-debuginfo for good measure. > Also, I can reproduce the traceback at will if I try to convert an Outlook > meeting to an appointment. Here's the new traceback with all the debuginfo: Nice, thanks. Please open a separate bug report for this in evolution-ews, to not steal this bug report. Thanks in advance.
Created Bug 740772
(In reply to comment #18) > I've just got the getenv/putenv crash too, on Fedora 21, and it led me to: > https://github.com/libical/libical/issues/86 > > I think I have a patch for it, to libical, to avoid putenv() completely. If the > crash was caused by this, then we are almost there. Here is the change for libical I was talking about: http://lists.infradead.org/pipermail/libical-devel/2014-November/000630.html
*** Bug 734020 has been marked as a duplicate of this bug. ***
*** Bug 688795 has been marked as a duplicate of this bug. ***
FWIW: I still get this with evolution-data-server-3.12.9-2.fc21.x86_64 libical-1.0-8.fc21.x86_64. But because this is already in RH BZ I don't get an opportunity to submit another abrt report.
(In reply to comment #26) > FWIW: I still get this with evolution-data-server-3.12.9-2.fc21.x86_64 Because it's not fixed yet in that version. See comment 20.
(In reply to comment #27) > (In reply to comment #26) > > FWIW: I still get this with evolution-data-server-3.12.9-2.fc21.x86_64 > > Because it's not fixed yet in that version. See comment 20. Comment 20 says 3.12.9+, thus yes, it is fixed in 3.12.9 and later versions. Well, it is supposed to be fixed there. Brian, do you have a reliable reproducer, please? It can be that one of your remote (possibly CalDAV) calendars changed on the server, and a corresponding backend in the calendar-factory updates its local cache, during which some memory corruption happens. One way was with the e_cal_backend_sexp_match_comp(), which happened with certain thread interleaving. That one is fixed. If there are more places, then I didn't spot them during the reproducer on my side. I'd suggest to make a copy of ~/.cache/evolution/calendar, which has stored local copy of the remote calendars in certain state (you might be able to reproduce the local cache update by returning the files back). Then wait whether the crash will happen. A way to debug this can be by using valgrind, to run the evolution-calendar-factory under it, but due to the memory checking the thread interleaving can change and the memory corruption can be avoided. Valgrind can also prevent certain types of crashes, but still log about them. I wrote a little how-to for a factory run under valgrind at [1], where it was for the addressbook factory, but here we want the calendar factory, thut that should be replaced at the steps. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1171770#c21
Milan, I don't think I do. I thought this was the one I was getting on every reboot (likely just every restart of evo*) but perhaps it's not. As André notes in comment 27, I'm still on 3.12.9 and the fixes that have been applied in comment 20 are for > 3.12.9 so I am probably just experiencing the original bug which has been fixed in > 3.12.9 only.
(In reply to comment #29) > ...As André notes in comment 27, I'm still on 3.12.9 and the fixes that have > been applied in comment 20 are for > 3.12.9... Nope. The notation I use, in this case "3.12.9+", means "the commit is available in version 3.12.9 and any later", thus you do have the fix in your evolution-data-server 3.12.9.
3.12.9+ meant to me everything that came after the tarball release of 3.12.9. So if you want to be clear, maybe "3.12.9 and later"?
(In reply to comment #30) > > Nope. The notation I use, in this case "3.12.9+", means "the commit is > available in version 3.12.9 and any later", That's always been my interpretation of that also. I was surprised to learn that I had been misunderstanding it for so long. Except that I hadn't been. :-) > thus you do have the fix in your > evolution-data-server 3.12.9. Indeed. And I am seeing this issue still.
(In reply to comment #31) > 3.12.9+ meant to me everything that came after the tarball release of 3.12.9. > So if you want to be clear, maybe "3.12.9 and later"? PEGI also uses this notation for age classes [1], that's where I met it for the first time and got to use it. Their "18+" means "suitable for 18 years old and later", not "suitable for 19 years old and later". [1] for example here: http://www.pegi.info/en/index/id/37/ They used to use the '+' in the markers too, if I recall correctly, but they have them dropped right now. (In reply to comment #32) > > thus you do have the fix in your > > evolution-data-server 3.12.9. > > Indeed. And I am seeing this issue still. Either this, or bug #736006 comment #19. I might mark the bugs as duplicates incorrectly in Fedora. Anyway, let's move to bug #736006 for further investigation.