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 736075 - Evolution calendar segfaults when viewing some emails in Evolution that have event invites
Evolution calendar segfaults when viewing some emails in Evolution that have ...
Status: RESOLVED DUPLICATE of bug 701138
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.12.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-09-04 18:21 UTC by Daniel Sands
Modified: 2014-10-14 06:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Sands 2014-09-04 18:21:33 UTC
I am using the EWS backend and also have a Google calendar.  When certain emails that have invites come up, I see an alert at the top that the calendar backend has quit unexpectedly.  Running the calendar backend in gdb, it's a segfault while deleting an interval tree related to the Google calendar.  I ran it again in Valgrind and got this:

==2944== Invalid read of size 8
==2944==    at 0xC930DC5: g_type_check_instance_is_fundamentally_a (gtype.c:3979)
==2944==    by 0xC911F06: g_object_unref (gobject.c:3067)
==2944==    by 0x4E4FD75: e_intervaltree_remove (e-cal-backend-intervaltree.c:668)
==2944==    by 0x4E50084: e_intervaltree_insert (e-cal-backend-intervaltree.c:513)
==2944==    by 0x4E55EA8: e_cal_backend_store_put_component_with_time_range (e-cal-backend-store.c:1240)
==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==    by 0x195F3195: caldav_get_object (e-cal-backend-caldav.c:1699)
==2944==    by 0x4E52963: cal_backend_get_object (e-cal-backend-sync.c:638)
==2944==    by 0x4E49BA9: cal_backend_get_object_thread (e-cal-backend.c:1894)
==2944==    by 0x4E47751: cal_backend_dispatch_thread (e-cal-backend.c:241)
==2944==    by 0xCBC0337: g_thread_pool_thread_proxy (gthreadpool.c:307)
==2944==  Address 0x31284c40 is 368 bytes inside a block of size 408 free'd
==2944==    at 0x4C2CCE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2944==    by 0xCB9E80E: g_free (gmem.c:190)
==2944==    by 0xCBB5C33: g_slice_free1 (gslice.c:1112)
==2944==    by 0xC92FC68: g_type_free_instance (gtype.c:1929)
==2944==    by 0x195F0C37: put_server_comp_to_cache (e-cal-backend-caldav.c:3249)
==2944==    by 0x195F3195: caldav_get_object (e-cal-backend-caldav.c:1699)
==2944==    by 0x4E52963: cal_backend_get_object (e-cal-backend-sync.c:638)
==2944==    by 0x4E49BA9: cal_backend_get_object_thread (e-cal-backend.c:1894)
==2944==    by 0x4E47751: cal_backend_dispatch_thread (e-cal-backend.c:241)
==2944==    by 0xCBC0337: g_thread_pool_thread_proxy (gthreadpool.c:307)
==2944==    by 0xCBBF9A4: g_thread_proxy (gthread.c:764)
==2944==    by 0xBADF5F9: start_thread (pthread_create.c:310)
==2944== 
==2944== Invalid read of size 8
==2944==    at 0xC930DCD: g_type_check_instance_is_fundamentally_a (gtype.c:3981)
==2944==    by 0xC911F06: g_object_unref (gobject.c:3067)
==2944==    by 0x4E4FD75: e_intervaltree_remove (e-cal-backend-intervaltree.c:668)
==2944==    by 0x4E50084: e_intervaltree_insert (e-cal-backend-intervaltree.c:513)
==2944==    by 0x4E55EA8: e_cal_backend_store_put_component_with_time_range (e-cal-backend-store.c:1240)
==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==    by 0x195F3195: caldav_get_object (e-cal-backend-caldav.c:1699)
==2944==    by 0x4E52963: cal_backend_get_object (e-cal-backend-sync.c:638)
==2944==    by 0x4E49BA9: cal_backend_get_object_thread (e-cal-backend.c:1894)
==2944==    by 0x4E47751: cal_backend_dispatch_thread (e-cal-backend.c:241)
==2944==    by 0xCBC0337: g_thread_pool_thread_proxy (gthreadpool.c:307)
==2944==  Address 0xaaaaaaaaaaaaaaaa is not stack'd, malloc'd or (recently) free'd
==2944== 
==2944== 
==2944== Process terminating with default action of signal 11 (SIGSEGV)
==2944==  General Protection Fault
==2944==    at 0xC930DCD: g_type_check_instance_is_fundamentally_a (gtype.c:3981)
==2944==    by 0xC911F06: g_object_unref (gobject.c:3067)
==2944==    by 0x4E4FD75: e_intervaltree_remove (e-cal-backend-intervaltree.c:668)
==2944==    by 0x4E50084: e_intervaltree_insert (e-cal-backend-intervaltree.c:513)
==2944==    by 0x4E55EA8: e_cal_backend_store_put_component_with_time_range (e-cal-backend-store.c:1240)
==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==    by 0x195F3195: caldav_get_object (e-cal-backend-caldav.c:1699)
==2944==    by 0x4E52963: cal_backend_get_object (e-cal-backend-sync.c:638)
==2944==    by 0x4E49BA9: cal_backend_get_object_thread (e-cal-backend.c:1894)
==2944==    by 0x4E47751: cal_backend_dispatch_thread (e-cal-backend.c:241)
==2944==    by 0xCBC0337: g_thread_pool_thread_proxy (gthreadpool.c:307)

Perhaps an object reference is not being incremented?
Comment 1 Milan Crha 2014-10-14 06:26:09 UTC
Thanks for a bug report. This had been already filled, thus I mark this as a duplicate of it. I wasn't able to reproduce this myself, but I will give it a try again.

*** This bug has been marked as a duplicate of bug 701138 ***