Re: [Evolution] indefinite network connection timeouts, again

On Thu, 2015-07-09 at 12:48 -0400, Eugene Kanter wrote:
The problem is reproducible
when more then approximately 10-11 IMAP+ accounts are defined. I have
about 15 in my configuration and as long as total number of enabled
accounts is less then some number (I have 10 IMAP+ and 1 POP3 account
right now) the evolution starts fine. If I add any IMAP account to this
working set (or remove one and add two others) evolution does not start
in online mode and waits indefinitely.

the number 10 might have a clue on itself. GTask (part of glib library)
allows up to 10 running threads at the same time. The thing is that the
GTask is used not only directly by the evolution, but also indirectly
by the glib itself or other libraries. I guess what you face is that
you reached the 10 threads limit, while none of them can finish (and
free the resource), because it's waiting for another GTask thread to be
executed. It could happen, bugs against glib are filled for it. It also
depends on your glib version, as some changes were done in the GTask
during the time.

Evolution-data-server 3.16.1 contains [1], which avoids GTask usage in
one mail-related place. A similar change [2] was done in evolution too,
also for 3.16.1. I cannot tell whether it'll help in your case, but at
least it will not steal GTask threads.

To prove that you face the GTask thread starving, install debuginfo
packages for glib, evolution-data-server and evolution, then reproduce
the issue, then grab backtrace of the running evolution, in that odd
state. You can get the backtrace with command like this:
   $ 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).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]