[Webkit-unassigned] [Bug 96105] New: [GTK] calling webkitInit() from class_init() functions can cause deadlocks

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=96105

           Summary: [GTK] calling webkitInit() from class_init() functions
                    can cause deadlocks
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: danw at gnome.org


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.