Bug 135760 – [GTK] No IPC messages are sent when building WebKitGTK+ with VERSION_SCRIPT

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Carlos Garcia Campos]

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.

[Carlos Garcia Campos]

Created attachment 236289 [details]
Patch

[Philippe Normand]

Comment on attachment 236289 [details]
Patch

o_O

[Carlos Garcia Campos]

Committed r172385: <http://trac.webkit.org/changeset/172385>

[Csaba Osztrogonác]

(In reply to comment #3)
> Committed r172385: <http://trac.webkit.org/changeset/172385>

Unfortunately it broke the EFL build: http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/2883

It's strange why the EFL EWS didn't notice it before. 
Maybe ENABLE_DRT environment variable isn't set on them.

The build fails on the EFL layout tester and the EFL performance
tester bots where ENABLE_DRT is set to 1. But the build doesn't 
fail on the ARM bots of u-szeged where ENABLE_DRT isn't present.

[Carlos Garcia Campos]

(In reply to comment #4)
> (In reply to comment #3)
> > Committed r172385: <http://trac.webkit.org/changeset/172385>
> 
> Unfortunately it broke the EFL build: http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/2883

I'm sorry, I assumed green EWS was safe enough.

> It's strange why the EFL EWS didn't notice it before. 
> Maybe ENABLE_DRT environment variable isn't set on them.
> 
> The build fails on the EFL layout tester and the EFL performance
> tester bots where ENABLE_DRT is set to 1. But the build doesn't 
> fail on the ARM bots of u-szeged where ENABLE_DRT isn't present.

I guess we just need to add WTF to any other target.

[Carlos Garcia Campos]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Committed r172385: <http://trac.webkit.org/changeset/172385>
> > 
> > Unfortunately it broke the EFL build: http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/2883
> 
> I'm sorry, I assumed green EWS was safe enough.
> 
> > It's strange why the EFL EWS didn't notice it before. 
> > Maybe ENABLE_DRT environment variable isn't set on them.
> > 
> > The build fails on the EFL layout tester and the EFL performance
> > tester bots where ENABLE_DRT is set to 1. But the build doesn't 
> > fail on the ARM bots of u-szeged where ENABLE_DRT isn't present.
> 
> I guess we just need to add WTF to any other target.

Ok, so the difference between ENABLE_DRT present or not is that it uses -DSHARED_CORE=ON, which is very confusing IMO. So the problem is not building DRT or whatever, but building with SHARED_CORE

[Carlos Garcia Campos]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > Committed r172385: <http://trac.webkit.org/changeset/172385>
> > > 
> > > Unfortunately it broke the EFL build: http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/2883
> > 
> > I'm sorry, I assumed green EWS was safe enough.
> > 
> > > It's strange why the EFL EWS didn't notice it before. 
> > > Maybe ENABLE_DRT environment variable isn't set on them.
> > > 
> > > The build fails on the EFL layout tester and the EFL performance
> > > tester bots where ENABLE_DRT is set to 1. But the build doesn't 
> > > fail on the ARM bots of u-szeged where ENABLE_DRT isn't present.
> > 
> > I guess we just need to add WTF to any other target.
> 
> Ok, so the difference between ENABLE_DRT present or not is that it uses -DSHARED_CORE=ON, which is very confusing IMO. So the problem is not building DRT or whatever, but building with SHARED_CORE

So, even though I don't understand why it fails, I guess we can just add WTF to the list of wk2 libs only when SHARED_CORE is ON (this will never be ON for GTK+)

[Gyuyoung Kim]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > (In reply to comment #3)
> > > > > Committed r172385: <http://trac.webkit.org/changeset/172385>
> > > > 
> > > > Unfortunately it broke the EFL build: http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/2883
> > > 
> > > I'm sorry, I assumed green EWS was safe enough.
> > > 
> > > > It's strange why the EFL EWS didn't notice it before. 
> > > > Maybe ENABLE_DRT environment variable isn't set on them.
> > > > 
> > > > The build fails on the EFL layout tester and the EFL performance
> > > > tester bots where ENABLE_DRT is set to 1. But the build doesn't 
> > > > fail on the ARM bots of u-szeged where ENABLE_DRT isn't present.
> > > 
> > > I guess we just need to add WTF to any other target.
> > 
> > Ok, so the difference between ENABLE_DRT present or not is that it uses -DSHARED_CORE=ON, which is very confusing IMO. So the problem is not building DRT or whatever, but building with SHARED_CORE
> 
> So, even though I don't understand why it fails, I guess we can just add WTF to the list of wk2 libs only when SHARED_CORE is ON (this will never be ON for GTK+)


This is long term issue on EFL port. Currently EFL port can't run layout test without SHARED_CORE=ON. To fix this issue, I filed a bug. However, it is still opened.

[EFL] Can't run layout test without SHARED_CORE=ON
https://bugs.webkit.org/show_bug.cgi?id=80683

It looks EFL EWS doesn't enable SHARED_CORE yet though buildbot enables it. That's why EWS didn't detect this build break. Let me talk how to fix this problem with my co-workers soon.

Anyway, I add WTF library for EFL port at the moment. 
http://trac.webkit.org/changeset/172392