GNOME Bugzilla – Bug 365258
GtkHTML app locks when using gthread
Last modified: 2017-07-30 16:01:32 UTC
Steps to reproduce: 1. Run an application that uses the GtkHTML widget and has threads enable (g_threads_init, gdk_threads_init, gdk_threads_enter). test.c is attached. 2. The aplication is single threaded (no lock from another thread), but has called g_thread_init. 3. Load any html. Click on links, scroll up and down, click on links... 4. The mouse clicks are locked (the mouse is moved). You can't click on other applications (i.e. gnome-panel), but the keyboard is working. The effect is that the whole desktop is locked, since you click everywhere and anything happens. 5. To unlock the mouse clicks, I kill the failing application. Also, changing the workspace with a keyboard shortcut makes the mouse to click again. Stack trace:
+ Trace 78422
Other information: I've reproduced it on two different machines, one with FC 4 (Gnome 2.10) and Ubuntu 5.10 (Gnome 2.12.1). Both display a similar stack trace (included one is for Ubuntu 5.10). That is, gdk_event_prepare->gdk_threads_impl_lock->_L_mutex_lock_* I've used gtkhtml3-3.13.tar.gz package from ftp.gnome.org. The attached test.c application is the original test.c source found on the gtkhtml3 package, i've only added the g_threads_init, gdk_threads_init and gdk_threads_enter calls at the beginning of main ().
Created attachment 75439 [details] Test.c app Test.c app, as included on GtkHTML source, with threads enabled
Forgot to mention: I've used Test2 test from the drop-down list. It displays link images of the Gnome logo. By clicking on this links, scrolling down the page, and clickin the links again you should reproduce it.
Hi all, i've found and fixed the bug I reported. The error was here, on gtkhtml.c: static gint idle_handler (gpointer data) { GtkHTML *html; HTMLEngine *engine; + GDK_THREADS_ENTER (); ... + GDK_THREADS_LEAVE (); return FALSE; } idle_handler() was missing surrounding GDK_THREADS_ENTER / _LEAVE calls. Due to this, idle_handler returned and left the global mutex locked, however it should have been unlocked because idle_handler was called from the idle loop. As the mutex was locked, when GTK+ tried to acquire the lock again the thread got locked (as seen on the previous stack trace). I hope this fix is applied soon, cause it's very important for the app I'm developing for my final project! I've verified this patch fixes the bug on libgtkhtml-3.6, I'll verify the fix for 3.13 today. Regards!
Bumping version to a stable release.
For starters, GtkHTML is full of idle handlers that are not using gdk_threads_add_idle(). That's going to cause issues with applications using threads. I wouldn't be surprised if this is also causing the crasher in bug 558076.
So it sounds like the thing to do is a mass s/g_idle_add/gdk_threads_add_idle/ throughout GtkHtml and possibly in many parts of Evolution?
This ticket has not seen any updates or duplicates since 2010. Is this still a problem in a recently released version? If not, this ticket might get closed as obsolete. (Furthermore, GtkHtml is slowly getting superseded by WebKit in Evolution.)
GtkHtml is not under active development anymore. Evolution (its main consumer) switched to a WebKit backend a while ago. It is currently unlikely that there will be any further GtkHtml development. Closing this report as WONTFIX as part of Bugzilla Housekeeping (bug 778387) to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.