After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 701138 - Make e_cal_backend_sexp_match_comp() thread safe
Make e_cal_backend_sexp_match_comp() thread safe
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.12.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 688795 734020 736075 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-05-28 15:14 UTC by David Woodhouse
Modified: 2015-01-12 12:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Woodhouse 2013-05-28 15:14:24 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.

Thread 140736506865408 (LWP 12022)

  • #0 __memset_sse2
    at ../sysdeps/x86_64/memset.S line 334
  • #1 memset
    at /usr/include/bits/string3.h line 84
  • #2 e_memchunk_alloc0
    at e-memory.c line 151
  • #3 e_sexp_result_new
    at e-sexp.c line 191
  • #4 e_sexp_term_eval
    at e-sexp.c line 751
  • #5 e_sexp_term_eval
    at e-sexp.c line 780
  • #6 e_sexp_term_eval
    at e-sexp.c line 780
  • #7 term_eval_and
    at e-sexp.c line 288
  • #8 e_sexp_term_eval
    at e-sexp.c line 772
  • #9 e_sexp_eval
    at e-sexp.c line 1698
  • #10 e_cal_backend_sexp_match_comp
    at e-cal-backend-sexp.c line 1254
  • #11 e_data_cal_view_component_matches
  • #12 e_cal_backend_notify_component_created
    at e-cal-backend.c line 1745
  • #13 put_server_comp_to_cache
    at e-cal-backend-caldav.c line 3159
  • #14 caldav_server_query_for_uid
    at e-cal-backend-caldav.c line 1609
  • #15 caldav_get_object
    at e-cal-backend-caldav.c line 4648
  • #16 cal_backend_get_object
  • #17 operation_thread
    at e-data-cal.c line 521
  • #18 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #19 g_thread_proxy
    at gthread.c line 798
  • #20 start_thread
    at pthread_create.c line 308
  • #21 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 113
  • #2 e_memchunk_alloc0
    at e-memory.c line 151
$2 = (void *) 0x80008001f690
(gdb) x/40x mem
0x80008001f690:	Cannot access memory at address 0x80008001f690
Comment 1 Matthew Barnes 2013-05-28 15:52:09 UTC
Can you get a backtrace on the first CRITICAL warning please?
Comment 2 David Woodhouse 2013-05-28 15:58:43 UTC
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
Comment 3 Matthew Barnes 2013-05-28 16:51:35 UTC
Valgrind even better, thanks!
Comment 4 Milan Crha 2013-09-30 08:30:31 UTC
Similar downstream bug report from 3.9.92:
https://bugzilla.redhat.com/show_bug.cgi?id=1013213
Comment 5 Milan Crha 2013-11-22 15:09:07 UTC
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.
Comment 6 Matthew Barnes 2013-11-22 15:39:31 UTC
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.
Comment 7 Matthew Barnes 2013-11-22 15:43:52 UTC
From my core file:

Program terminated with signal 11, Segmentation fault.
  • #0 g_type_check_instance_is_a
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gtype.c line 3999
  • #0 g_type_check_instance_is_a
    at /build/glib2.0-Ot8bbC/glib2.0-2.36.4/./gobject/gtype.c line 3999
  • #1 g_object_unref
    from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
  • #2 e_intervaltree_remove
    at e-cal-backend-intervaltree.c line 652
  • #3 e_intervaltree_insert
    at e-cal-backend-intervaltree.c line 504
  • #4 e_cal_backend_store_put_component_with_time_range
    at e-cal-backend-store.c line 1201
  • #5 put_component_to_store
    at e-cal-backend-http.c line 397
  • #6 cal_backend_http_load
    at e-cal-backend-http.c line 677
  • #7 cal_backend_http_load
    at e-cal-backend-http.c line 567
  • #8 begin_retrieval_cb
    at e-cal-backend-http.c line 775
  • #9 io_job_thread
    from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
  • #10 g_task_thread_pool_thread
    from /usr/lib/i386-linux-gnu/libgio-2.0.so.0
  • #11 g_thread_pool_thread_proxy
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #12 g_thread_proxy
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #13 start_thread
    at pthread_create.c line 311
  • #14 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 131

Not exactly the same as David's, but also crashing in EIntervalTree.

Seems we have some thread-safety issues there.
Comment 8 Milan Crha 2013-11-22 19:32:36 UTC
I guess it's late to backup your local cache for that google calendar, right?
Comment 9 Milan Crha 2014-04-29 14:10:46 UTC
Downstream bug report about the same from 3.10.4:
https://bugzilla.redhat.com/show_bug.cgi?id=1091567

Thread 1 (Thread 0x7f73c27fc700 (LWP 23223))

  • #0 __GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 56
  • #1 __GI_abort
    at abort.c line 89
  • #2 _g_log_abort
    at gmessages.c line 255
  • #3 g_assertion_message
    at gtestutils.c line 2278
  • #4 g_assertion_message_expr
    at gtestutils.c line 2293
  • #5 e_sexp_result_free
    at e-sexp.c line 220
  • #6 e_sexp_resultv_free
    at e-sexp.c line 234
  • #7 e_sexp_term_eval
    at e-sexp.c line 788
  • #8 e_sexp_eval
    at e-sexp.c line 1698
  • #9 e_cal_backend_sexp_match_comp
    at e-cal-backend-sexp.c line 1254
  • #10 e_data_cal_view_component_matches
    at e-data-cal-view.c line 940
  • #11 e_cal_backend_notify_component_created
    at e-cal-backend.c line 4098
  • #12 put_server_comp_to_cache
    at e-cal-backend-caldav.c line 3261
  • #13 caldav_server_query_for_uid
    at e-cal-backend-caldav.c line 1686
  • #14 caldav_get_object
    at e-cal-backend-caldav.c line 4761
  • #15 cal_backend_get_object
    at e-cal-backend-sync.c line 629
  • #16 cal_backend_get_object_thread
    at e-cal-backend.c line 1719
  • #17 cal_backend_dispatch_thread
    at e-cal-backend.c line 233
  • #18 io_job_thread
    at gioscheduler.c line 89
  • #19 g_task_thread_pool_thread
    at gtask.c line 1245
  • #20 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #21 g_thread_proxy
    at gthread.c line 798
  • #22 start_thread
    at pthread_create.c line 309
  • #23 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111

Comment 10 Milan Crha 2014-09-01 10:36:40 UTC
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.

Thread 1 (Thread 0x7fee1f7fe700 (LWP 2522))

  • #0 e_cal_backend_notify_component_modified
    at e-cal-backend.c line 4329
  • #1 put_server_comp_to_cache
    at e-cal-backend-caldav.c line 3236
  • #2 synchronize_cache
    at e-cal-backend-caldav.c line 2451
  • #3 caldav_synch_slave_loop
    at e-cal-backend-caldav.c line 2584
  • #4 g_thread_proxy
    at gthread.c line 764
  • #5 start_thread
    at pthread_create.c line 310
  • #6 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 109

Comment 11 Milan Crha 2014-10-14 06:26:10 UTC
*** Bug 736075 has been marked as a duplicate of this bug. ***
Comment 12 Milan Crha 2014-10-14 13:20:02 UTC
(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.
Comment 13 Daniel Sands 2014-10-14 16:48:12 UTC
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.
Comment 14 Milan Crha 2014-10-15 07:17:45 UTC
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.
Comment 15 André Klapper 2014-11-03 08:43:41 UTC
(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.
Comment 16 Daniel Sands 2014-11-25 21:22:16 UTC
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)
Comment 17 Milan Crha 2014-11-26 07:20:46 UTC
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.
Comment 18 Milan Crha 2014-11-26 13:17:11 UTC
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.
Comment 19 Daniel Sands 2014-11-26 18:27:13 UTC
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>
Comment 20 Milan Crha 2014-11-26 18:29:41 UTC
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
Comment 21 Milan Crha 2014-11-26 18:30:36 UTC
(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.
Comment 22 Daniel Sands 2014-11-26 18:48:38 UTC
Created Bug 740772
Comment 23 Milan Crha 2014-11-27 11:38:36 UTC
(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
Comment 24 Milan Crha 2014-11-28 11:08:23 UTC
*** Bug 734020 has been marked as a duplicate of this bug. ***
Comment 25 Milan Crha 2015-01-05 17:53:09 UTC
*** Bug 688795 has been marked as a duplicate of this bug. ***
Comment 26 Brian J. Murrell 2015-01-07 15:41:24 UTC
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.
Comment 27 André Klapper 2015-01-07 17:10:13 UTC
(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 28 Milan Crha 2015-01-08 08:37:21 UTC
(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
Comment 29 Brian J. Murrell 2015-01-08 13:53:13 UTC
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.
Comment 30 Milan Crha 2015-01-09 07:28:28 UTC
(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.
Comment 31 André Klapper 2015-01-09 14:00:27 UTC
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"?
Comment 32 Brian J. Murrell 2015-01-10 15:59:48 UTC
(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.
Comment 33 Milan Crha 2015-01-12 12:29:26 UTC
(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.