Bug 67281 – The GDK lock is not held around GDK/GTK locks when they are from callbacks

• Component: WebKitGTK
• Status: RESOLVED LATER

[Yehouda Harpaz]

Created attachment 105770 [details]
Backtraces demonstarting GDK calls without GDK lock

The GDK lock is not held around GDK/GTK locks when they are from callbacks that are passed to soup functions.

For example, in the first backtrace gdk_window_invalidate_rect is called (it tails calls gdk_window_invalidate_rect_full, which is what you see in the backtrace). Nothing holds the lock at that point. 

In this backtrace WebCore is called Soup via the callback WebCore::readCallback. 

The second backtrace shows the same problem with a callback from a timeout vi WebCore::timeout_cb. The third backtrace is the same as the first. The fourth backtrace shows the same call to GDK, but via another route where the GDK lock is held. 

There was a discussion about this the webkit-gtk mailing list, subject is "What supposed to hold the GDK in calls from WebKit/gtk/WebCoreSupport":
https://lists.webkit.org/pipermail/webkit-gtk/2011-August/000645.html

See also https://bugs.webkit.org/show_bug.cgi?id=30876

Currently we cannot use webkitgtk, because we do multi-threading and without the lock it is not thread-safe.

[Yehouda Harpaz]

I changed it to blocker, because as the original report says, we cannot use it at all as it is.

[Martin Robinson]

Going to close this for now until we need to re-approach the issue for WebKit2.