[Webkit-unassigned] [Bug 135760] New: [GTK] No IPC messages are sent when building WebKitGTK+ with VERSION_SCRIPT

[bugzilla-daemon at webkit.org]

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

           Summary: [GTK] No IPC messages are sent when building
                    WebKitGTK+ with VERSION_SCRIPT
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: cgarcia at igalia.com
                CC: gns at gnome.org, mrobinson at webkit.org, berto at igalia.com
            Blocks: 135694


Everything fails because of the threading initialization, this is what is happening:

1. InitializeWebKit2 is called when the first API object is created in the UI process

2. InitializeWebKit2 calls 

  JSC::initializeThreading(); 
  WTF::initializeMainThread();

3. We have two copies of WTF in memory and JSC::initializeThreading() is using one, and WTF::initializeMainThread() the other, see:

$ objdump -t libjavascriptcoregtk-4.0.so | grep ThreadIdentifierData
0000000000000000 l    df *ABS*    0000000000000000              ThreadIdentifierDataPthreads.cpp
00000000006e3290 g     F .text    000000000000005f              _ZN3WTF20ThreadIdentifierData10identifierEv
00000000006e32f0 g     F .text    0000000000000056              _ZN3WTF20ThreadIdentifierData10initializeEj
00000000006e31b0 g     F .text    0000000000000025              _ZN3WTF20ThreadIdentifierDataD1Ev
00000000006e31e0 g     F .text    0000000000000053              _ZN3WTF20ThreadIdentifierData8destructEPv
00000000006e31b0 g     F .text    0000000000000025              _ZN3WTF20ThreadIdentifierDataD2Ev
00000000009d6da8 g     O .data    0000000000000004              _ZN3WTF20ThreadIdentifierData5m_keyE
00000000006e3240 g     F .text    000000000000004b              _ZN3WTF20ThreadIdentifierData14initializeOnceEv

$ objdump -t libwebkit2gtk-4.0.so | grep ThreadIdentifierData
0000000000000000 l    df *ABS*    0000000000000000              ThreadIdentifierDataPthreads.cpp
0000000000700150 l     F .text    0000000000000025              _ZN3WTF20ThreadIdentifierDataD1Ev
0000000000700290 l     F .text    0000000000000056              _ZN3WTF20ThreadIdentifierData10initializeEj
0000000000700230 l     F .text    000000000000005f              _ZN3WTF20ThreadIdentifierData10identifierEv
0000000000700180 l     F .text    0000000000000053              _ZN3WTF20ThreadIdentifierData8destructEPv
00000000023efe1c l     O .data    0000000000000004              _ZN3WTF20ThreadIdentifierData5m_keyE
0000000000700150 l     F .text    0000000000000025              _ZN3WTF20ThreadIdentifierDataD2Ev
00000000007001e0 l     F .text    000000000000004b              _ZN3WTF20ThreadIdentifierData14initializeOnceEv

JSC::initializeThreading() calls ThreadIdentifierData::initializeOnce() but using the symbol in libjavascriptcoregtk-4.0.so, so it initializes the pthread_key_t ThreadIdentifierData::m_key in libjavascriptcoregtk-4.0.so. Then WTF::initializeMainThread() calls currentThread() to initialize the main thread identificator, that ends up calling ThreadIdentifierData::identifier() but this time using the local symbol in libwebkit2gtk-4.0.so. The ThreadIdentifierData::m_key in libwebkit2gtk-4.0.so is never initialized with pthread_key_create, and then all calls to pthread_setspecific use 1024 and fails with EINVAL.
Everything depending on the main thread fails, because isMainThread is always returning false, so for example, we are creating a new GMainContext in runLoop instead of using the default one, and all sources scheduled in the main run loop are not processed at all.

The solution is to not link explicitly WebKit2 to WTF, because WebKit2 already links to JavaScriptCore, and then only the JSC copy (with the global symbols) is used. That's what autotools build used to do as well, I think.

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