GNOME Bugzilla – Bug 686810
[regression] Infinite wait in g_task_run_in_thread_sync()
Last modified: 2012-11-02 14:20:50 UTC
I've reported something like this before and it has been fixed for a month or so. I started the git/master (as of Oct 16) of evo and friends; after a short while the status bar was filled with various processes that don't seem to end. I've been updating various gnome components to their 3.7.0 versions, and I suspect that's what triggered the problem. Here's a backtrace:
+ Trace 231084
Thread 1 (Thread 0xb0a298a0 (LWP 12262))
Thanks for a bug report. I see most of the threads are waiting for a resolution of www.segalcentre.org, then one for newsletter.inpix.ca. The main thread is repainting the window. Is any process eating your CPU? Is evolution one of them? I saw high CPU usage of a spinner animation (the circle in the status bar indicating the process didn't freeze), which could block evolution from its usual behaviour. Maybe this is similar.
Hi Milan (welcome back), Evo was using a lot of CPU, but I neglected to look at it by thread.
(In reply to comment #2) > Hi Milan (welcome back), Thanks :) > Evo was using a lot of CPU, but I neglected to look at it by thread. Try to involve the sysprof or any similar tool, to see what is causing the high CPU usage. 3.6.0 of GTK has sever issue with spinner (or any other) animation, which was supposed to be fixed in 3.6.1, but not that well. See bug #684639 for more information on this. I also got high CPU usage while creating new message (when the composer is created), which seems to be due to CSS style context on the first look, but I'm not a gtk+ developer, thus I cannot tell for sure.
The problem doesn't arise if I don't load images from the internet, which is consistent with your last comment. I've reported something like this before in bug 680463.
*** Bug 680463 has been marked as a duplicate of this bug. ***
I see. Is the message a spam message or an expected delivery? I mean, would it be possible to share one such message, please? If it contains any private information in it, then feel free to zip it and send it to me privately, just mention the bug number in the subject, thus I'll not get it lost between my spam. Thanks in advance.
The message wasn't spam, just an e-mail with a html link to an image. Note that this is not completely reproducible, in that it seems to involve some networking problem which keeps the image from loading or allowing me to kill the thread.
Thanks for the message (sent privately). It works for me, of course, but I use different glib version, where is no gtask.c available. Looking into the backtrace again, I suppose there is kind of a deadlock in g_task_run_in_thread_sync(), thus I'm moving this to glib/gio. I'm pasting here one of the threads too:
+ Trace 231107
Thread 11 (Thread 0x9ef98b70 (LWP 12323))
Well, that thread is waiting for a GCond to be triggered, so I need to see what the other threads are doing that's causing the GCond to not get triggered
check comment #0 for the full thread.
Oh, oops, misread your earlier comment about a private message and thought the stack trace came from that... The problem is that currently GTask will only allow 10 outstanding threads at once, and there are at least 10 handle_http_request() threads, so no more g_task_run_in_thread() threads can be started, but now each of those handle_http_request() threads is stuck waiting for a DNS thread to finish, except that it can't even start... temporary workaround: bump up the pool size. longer-term fix: bug 687223
Created attachment 227670 [details] [review] gtask: bump the max thread pool size up to 100 to avoid stalls/deadlocks Fixes https://bugzilla.gnome.org/show_bug.cgi?id=686810 for now. https://bugzilla.gnome.org/show_bug.cgi?id=687223 discusses a nicer fix for later.
Review of attachment 227670 [details] [review]: Why not 1000 or 10000? Dunno. 100 is OK by me as long as we do the real fix eventually...
Hi Dan, The patch "fixes" the problem. It might be useful to show a warning message if the number of tasks ever hits the maximum (perhaps also with a query as to whether to continue or not) until the more elegant fix is available.
Attachment 227670 [details] pushed as 7b1f8c5 - gtask: bump the max thread pool size up to 100 to avoid stalls/deadlocks