GNOME Bugzilla – Bug 765916
Reconnecting hangs
Last modified: 2016-05-04 07:24:36 UTC
Created attachment 327184 [details] Screenshot of reconnecting Evolution 3.18.5.1 sometimes shows "Reconnecting" message in the statusbar indefinite time. When this happens, it is impossible to close the Evolution window with the window's manager Close icon. This time (I wonder why) it shows "Reconnecting to 'On This Computer'". I don't know what reconnecting to this computer means. The screenshot attached.
Thanks for a bug report. I think what you face is an issue with glib GTask, which has limited amount of threads, which caused a starving on your machine (some ongoing operation which runs in a GTask thread requires another GTask thread to be running, which is scheduled in the pool, but is not processed, due to the limit of the running threads being reached, thus the first thread starving indefinitely). Could you install debuginfo packages for the evolution-data-server, evolution and glib2 (only for these packages, their dependencies are not needed, definitely not the webkitgtk3), then, once you get into this state again, capture a backtrace of the running evolution using this command: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). Finally share the backtrace here, thus I could verify whether my hypothesis about the GTask threads was correct or not. Thanks in advance. Also, could you provide your glib (some distributions package it as glib2) version, please?
Glib 2.48.0, bt.txt: [New LWP 21501] [New LWP 21478] [New LWP 21475] [New LWP 21474] [New LWP 21473] [New LWP 21472] [New LWP 21471] [New LWP 21470] [New LWP 21469] [New LWP 21468] [New LWP 21445] [New LWP 21444] [New LWP 21443] [New LWP 21442] [New LWP 21441] [New LWP 21440] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". 0xb7708be0 in __kernel_vsyscall ()
+ Trace 236222
Thanks for the backtrace. Looking at it, it's a different thing than the GTask issue I thought of. This is bug #742167, thus I mark this as a duplicate of it. *** This bug has been marked as a duplicate of bug 742167 ***