GNOME Bugzilla – Bug 669460
[abrt] Can pick freed connection
Last modified: 2012-07-16 19:49:29 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=787514 libreport version: 2.0.8 abrt_version: 2.0.7 backtrace_rating: 4 cmdline: evolution crash_function: strcmp executable: /usr/bin/evolution kernel: 3.1.9-1.fc16.x86_64 reason: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) time: Sat 04 Feb 2012 08:10:28 AM PST Core was generated by `evolution'. Program terminated with signal 11, Segmentation fault.
+ Trace 229610
Thread 5 (Thread 0x7fb547de5700 (LWP 7753))
Similar issue from Fedora 17 (evolution-ews 3.4.1): https://bugzilla.redhat.com/show_bug.cgi?id=827488
+ Trace 230302
Thread 1 (Thread 0x7f0961a1c700 (LWP 27469))
From another similar downstream bug report I suspect that EWS picked old connection and was going to reuse it, which it was freed either already or meanwhile. The other crash happened in e_ews_connection_new g_object_set (G_OBJECT (cnc->priv->soup_session), SOUP_SESSION_USE_NTLM, use_ntlm, NULL); ews_connect_sync when the cnc is set to 0x8d74220, which is not that suspicious, but the xsession_error contains a warning: GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed which can be from just few lines before the g_object_set() call.
Created attachment 218936 [details] [review] ews patch for evolution-ews; This may fix it. The e_ews_connection_dispose didn't use 'connecting' lock when accessing 'loaded_connections_permissions' hash table, thus one thread could disposing the connection while another could pick it as working, leading into using freed memory in the other thread.
Created commit b7f5053 in ews master (3.5.5+) Created commit e867f70 in ews gnome-3-4 (3.4.4+)