Bug 691350 – [abrt] Crash in CalDAV when going offline

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 691350 - [abrt] Crash in CalDAV when going offline


Summary:	[abrt] Crash in CalDAV when going offline


Status:	RESOLVED INCOMPLETE

Product:	evolution-data-server
Classification:	Platform
Component:	Calendar
Version:	3.10.x (obsolete)
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	---
Assigned To:	evolution-calendar-maintainers
QA Contact:	Evolution QA team

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2013-01-08 16:06 UTC by Milan Crha
Modified:	2015-11-04 16:43 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Milan Crha 2013-01-08 16:06:58 UTC

Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=892913

Version-Release number of selected component:
evolution-data-server-3.4.4-4.fc17

Additional info:
libreport version: 2.0.18
abrt_version:   2.0.18
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-calendar-factory
crash_function: g_mutex_get_impl
kernel:         3.6.10-2.fc17.x86_64

Core was generated by `/usr/libexec/evolution-calendar-factory'.
Program terminated with signal 11, Segmentation fault.

+ Trace 231352

Thread 11 (Thread 0x7f1237a00800 (LWP 2563))

#0 g_dbus_connection_send_message
at gdbusconnection.c line 1711
#1 g_dbus_connection_emit_signal
at gdbusconnection.c line 5135
#2 e_gdbus_signal_emission_hook_boolean
at e-gdbus-templates.c line 99
#3 signal_emit_unlocked_R
at gsignal.c line 3517
#4 g_signal_emit_valist
at gsignal.c line 3300
#5 g_signal_emit
at gsignal.c line 3356
#6 e_gdbus_cal_emit_online
at e-gdbus-cal.c line 1213
#7 e_data_cal_report_online
at e-data-cal.c line 1511
#8 e_cal_backend_notify_online
at e-cal-backend.c line 1877
#9 g_closure_invoke
at gclosure.c line 777
#10 signal_emit_unlocked_R
at gsignal.c line 3551
#11 g_signal_emit_valist
at gsignal.c line 3300
#12 g_signal_emit
at gsignal.c line 3356
#13 g_object_dispatch_properties_changed
at gobject.c line 1041
#14 g_object_notify_queue_thaw
at gobject.c line 291
#15 g_object_set_property
at gobject.c line 2151
#16 on_source_notify
at gbinding.c line 379
#17 g_closure_invoke
at gclosure.c line 777
#18 signal_emit_unlocked_R
at gsignal.c line 3551
#19 g_signal_emit_valist
at gsignal.c line 3300
#20 g_signal_emit
at gsignal.c line 3356
#21 g_object_dispatch_properties_changed
at gobject.c line 1041
#22 g_object_notify_by_spec_internal
at gobject.c line 1133
#23 g_object_notify
at gobject.c line 1175
#24 e_data_factory_set_online
at e-data-factory.c line 404
#25 g_closure_invoke
at gclosure.c line 777
#26 signal_emit_unlocked_R
at gsignal.c line 3551
#27 g_signal_emit_valist
at gsignal.c line 3300
#28 g_signal_emit
at gsignal.c line 3356
#29 emit_network_changed
at gnetworkmonitorbase.c line 265
#30 g_main_dispatch
at gmain.c line 2539
#31 g_main_context_dispatch
at gmain.c line 3075
#32 g_main_context_iterate
at gmain.c line 3146
#33 g_main_loop_run
at gmain.c line 3340
#34 e_dbus_server_run
at e-dbus-server.c line 253
#35 main
at evolution-calendar-factory.c line 149

Comment 1 Milan Crha 2013-01-08 16:08:12 UTC

I see in the backtrace that the main thread is notifying about network change, going to offline, while the crashing thread is still sending a SoupMessage from CalDAV.

Comment 2 Milan Crha 2013-01-08 20:31:34 UTC

Dan, I'm not sure if I recall this correctly, but it is safe to SoupSessionSync functions from multiple threads in once, isn't it? I see that the CalDAV just calls soup_session_abort() when it gets offline, but it seems the SoupSession does something more, which can lead to this crash? I'm only guessing here, could you comment your opinion, please?

Comment 3 Dan Winship 2013-01-08 21:00:03 UTC

(In reply to comment #2)
> Dan, I'm not sure if I recall this correctly, but it is safe to SoupSessionSync
> functions from multiple threads in once, isn't it?

It's definitely supposed to be, yes.

Comment 4 Dan Winship 2013-01-11 15:54:52 UTC

+ Trace 231373

#0 g_mutex_get_impl
at gthread-posix.c line 119
#1 g_mutex_lock
at gthread-posix.c line 208
#2 soup_message_queue_item_unref
at soup-message-queue.c line 156


so clearly there's some sort of refcounting issue going on here... is it possible this is related to the thing you mentioned fixing in bug 691399 comment 3?

Comment 5 Milan Crha 2013-01-14 13:53:38 UTC

(In reply to comment #4)
> so clearly there's some sort of refcounting issue going on here... is it
> possible this is related to the thing you mentioned fixing in bug 691399
> comment 3?

I thought it's it, and I left there that commit, but I got the crash too, even with the ref on the backend, thus it seems like my consumption was wrong about the reference.

Comment 6 Milan Crha 2013-05-30 08:04:21 UTC

Similar downstream bug report from 3.8.2:
https://bugzilla.redhat.com/show_bug.cgi?id=968321

Core was generated by `/usr/libexec/evolution-calendar-factory'.
Program terminated with signal 11, Segmentation fault.

+ Trace 232004

Thread 17 (Thread 0x7f0e07421840 (LWP 1919))

#0 poll
at ../sysdeps/unix/syscall-template.S line 81
#1 g_main_context_poll
at gmain.c line 3995
#2 g_main_context_iterate
at gmain.c line 3696
#3 g_main_loop_run
at gmain.c line 3895
#4 dbus_server_run_server
at e-dbus-server.c line 222
#5 ffi_call_unix64
at ../src/x86/unix64.S line 76
#6 ffi_call
at ../src/x86/ffi64.c line 522
#7 g_cclosure_marshal_generic_va
at gclosure.c line 1550
#8 _g_closure_invoke_va
at gclosure.c line 840
#9 g_signal_emit_valist
at gsignal.c line 3234
#10 g_signal_emit
at gsignal.c line 3384
#11 e_dbus_server_run
at e-dbus-server.c line 414
#12 main
at evolution-calendar-factory.c line 140

Thread 16 (Thread 0x7f0dd9ffb700 (LWP 2031))

#0 strchrnul
at ../sysdeps/x86_64/strchrnul.S line 33
#1 __find_specmb
at printf-parse.h line 109
#2 _IO_vfprintf_internal
at vfprintf.c line 1308
#3 __GI___vasprintf_chk
at vasprintf_chk.c line 66
#4 vasprintf
at /usr/include/bits/stdio2.h line 210
#5 g_vasprintf
at gprintf.c line 314
#6 g_strdup_vprintf
at gstrfuncs.c line 517
#7 g_logv
at gmessages.c line 878
#8 g_log
at gmessages.c line 1010
#9 g_type_check_instance
at gtype.c line 4111
#10 g_signal_emit_valist
at gsignal.c line 3105
#11 g_signal_emit
at gsignal.c line 3384
#12 ffi_call_unix64
at ../src/x86/unix64.S line 76
#13 ffi_call
at ../src/x86/ffi64.c line 522
#14 g_cclosure_marshal_generic_va
at gclosure.c line 1550
#15 _g_closure_invoke_va
at gclosure.c line 840
#16 g_signal_emit_valist
at gsignal.c line 3234
#17 g_signal_emit
at gsignal.c line 3384
#18 g_socket_client_emit_event
at gsocketclient.c line 979
#19 g_socket_client_connect
at gsocketclient.c line 1202
#20 soup_socket_connect_sync
at soup-socket.c line 841
#21 soup_connection_connect_sync
at soup-connection.c line 676
#22 get_connection
at soup-session.c line 1775
#23 soup_session_process_queue_item
at soup-session.c line 1796
#24 soup_session_real_send_message
at soup-session.c line 2045
#25 send_and_handle_redirection
at e-cal-backend-caldav.c line 1044
#26 caldav_server_list_objects
at e-cal-backend-caldav.c line 1447
#27 synchronize_cache
at e-cal-backend-caldav.c line 2211
#28 caldav_synch_slave_loop
at e-cal-backend-caldav.c line 2517
#29 g_thread_proxy
at gthread.c line 798
#30 start_thread
at pthread_create.c line 308
#31 clone
at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 113

Thread 3 (Thread 0x7f0dcb7fe700 (LWP 2022))

#0 strchrnul
at ../sysdeps/x86_64/strchrnul.S line 33
#1 __find_specmb
#2 _IO_vfprintf_internal
#3 __GI___vasprintf_chk
#4 vasprintf
at /usr/include/bits/stdio2.h line 210
#5 g_vasprintf
at gprintf.c line 314
#6 g_strdup_vprintf
at gstrfuncs.c line 517
#7 g_logv
at gmessages.c line 878
#8 g_log
at gmessages.c line 1010
#9 g_type_check_instance
at gtype.c line 4118
#10 g_signal_emit_valist
at gsignal.c line 3105
#11 g_signal_emit
at gsignal.c line 3384
#12 ffi_call_unix64
at ../src/x86/unix64.S line 76
#13 ffi_call
at ../src/x86/ffi64.c line 522
#14 g_cclosure_marshal_generic_va
at gclosure.c line 1550
#15 _g_closure_invoke_va
at gclosure.c line 840
#16 g_signal_emit_valist
at gsignal.c line 3234
#17 g_signal_emit
at gsignal.c line 3384
#18 g_socket_client_emit_event
at gsocketclient.c line 979
#19 g_socket_client_connect
at gsocketclient.c line 1202
#20 soup_socket_connect_sync
at soup-socket.c line 841
#21 soup_connection_connect_sync
at soup-connection.c line 676
#22 get_connection
at soup-session.c line 1775
#23 soup_session_process_queue_item
at soup-session.c line 1796
#24 soup_session_real_send_message
at soup-session.c line 2045
#25 send_and_handle_redirection
at e-cal-backend-caldav.c line 1044
#26 caldav_server_list_objects
at e-cal-backend-caldav.c line 1447
#27 synchronize_cache
at e-cal-backend-caldav.c line 2211
#28 caldav_synch_slave_loop
at e-cal-backend-caldav.c line 2517
#29 g_thread_proxy
at gthread.c line 798
#30 start_thread
at pthread_create.c line 308
#31 clone
at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 113

Comment 7 Kevin R. Page 2013-12-24 11:05:23 UTC

Also occurring in evolution-data-server 3.10.2-2.fc20 (abrt matched downstream bug report).

https://retrace.fedoraproject.org/faf/reports/191233/

Comment 8 Milan Crha 2014-03-10 17:28:22 UTC

I'm updating the version accordingly. I'm still unsure what can cause this, or at least do not see it in the code.

Comment 9 Milan Crha 2015-11-04 16:43:41 UTC

This didn't receive any duplicates for a long time. Let's assume that 3.18.x (current stable series) behaves better.