[GTK] calling webkitInit() from class_init() functions can cause deadlocks

• Component: WebKitGTK
• Status: RESOLVED WONTFIX

[Dan Winship]

See, eg, https://bugzilla.gnome.org/page.cgi?id=trace.html&trace_id=230816 from https://bugzilla.gnome.org/show_bug.cgi?id=683548. This is caused because webkit_web_view_class_init() calls webkitInit(), and webkitInit() creates objects, which (apparently) you aren't supposed to do from inside a class_init() function.

In particular, gtype's class_init_rec_mutex is held during the class_init function, and so if you do things in your class_init that might grab other mutexes, then there's the possibility that another thread might grab those mutexes in the other order and deadlock. (In that stack trace, webkit_web_view_class_init() calls webkitInit(), which creates the default session, which ends up trying to grab default_modules_lock so it can load the default GProxyResolver plugin, but meanwhile another thread is loading the GTlsBackend plugin, which then tries to register classes...)

It's possible that class_init_rec_mutex might go away at some point (bgo 674885), but for now, it's there, and deadlocks can happen as a result.


I didn't look at webkitInit() in detail, but if you could call it from instance init functions instead of class init functions, that would fix things.

[Martin Robinson]

The GTK+ port of WebKit1 has been removed.