Oh... that's not surprising at all. It's set to that value initially: namespace WTF { pthread_key_t ThreadIdentifierData::m_key = PTHREAD_KEYS_MAX; ... So why the assertion? Don't we expect it to be PTHREAD_KEYS_MAX initially?

m_key is supposed to be setup in WTF::ThreadIdentifierData::initializeOnce(), which is called by initializeThreading WTF::initializeThreading(). I'm guessing WTF::initializeThreading() isn't getting called like we'd expect. Who is responsible for calling WTF::initializeThreading()? I don't see it being called anywhere in the library. I see it called in main() in some things in WTF/benchmarks. Is the client responsible for calling that? It seems odd that the library doesn't handle it.

Oh, I missed it. JSC::initializeThreading() calls WTF::initializeThreading(), and JSC::initializeThreading() is the first thing called by WebKit2::InitializeWebKit2 namespace JSC { void initializeThreading() { static std::once_flag initializeThreadingOnceFlag; std::call_once(initializeThreadingOnceFlag, []{ WTF::double_conversion::initialize(); WTF::initializeThreading(); ... --- void InitializeWebKit2() { #if PLATFORM(COCOA) InitWebCoreSystemInterface(); #endif #if PLATFORM(IOS) InitWebCoreThreadSystemInterface(); #endif JSC::initializeThreading(); WTF::initializeMainThread(); ... So that all looks OK, BUT the issue comes because of 2-level name-spacing. Here's the backtrace: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8ac13f06 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff8fa204ec pthread_kill + 90 2 libsystem_c.dylib 0x00007fff8b86e6e7 abort + 129 3 libsystem_c.dylib 0x00007fff8b835df8 __assert_rtn + 321 4 libwebkit2gtk-4.0.37.dylib 0x000000010b27cb54 WTF::ThreadIdentifierData::identifier() + 68 5 libwebkit2gtk-4.0.37.dylib 0x000000010b27db3d WTF::currentThread() + 13 6 libwebkit2gtk-4.0.37.dylib 0x000000010b222e32 WTF::initializeMainThread() + 34 7 libwebkit2gtk-4.0.37.dylib 0x0000000108e0236e WebKit::InitializeWebKit2() + 14 libwebkit2gtk's WTF::initializeMainThread() was never called. libjavascriptcoregtk has its own copy of WTF::initializeMainThread(), and THAT was what was called: webkitgtk-2.11.3/lib $ nm libjavascriptcoregtk-4.0.dylib | grep initializeOnce 0000000000ac29a0 T __ZN3WTF20ThreadIdentifierData14initializeOnceEv 0000000000e3f9f0 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce 0000000000e3fa30 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce webkitgtk-2.11.3/lib $ nm libwebkit2gtk-4.0.dylib | grep initializeOnce 0000000002634a00 T __ZN3WTF20ThreadIdentifierData14initializeOnceEv 0000000003702500 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce 00000000037024b0 b __ZZN3WTF12_GLOBAL__N_112myThreadDataEvE14initializeOnce

In webkit-gtk 2.4.x, WTF is not exported by libwebkitgtk. It's exported by libjavascriptcoregtk. Thus, I suspect the appropriate fix is to remove WTF from libwebkit2gtk. This was likely fallout from the autoconf -> cmake transition.

(In reply to comment #4) > In webkit-gtk 2.4.x, WTF is not exported by libwebkitgtk. It's exported by > libjavascriptcoregtk. Thus, I suspect the appropriate fix is to remove WTF > from libwebkit2gtk. This was likely fallout from the autoconf -> cmake > transition. Sounds fine to me. In Source/WebKit2/CMakeLists.txt, try removing JavaScriptCore (which depends on WTF) from here: set(WebKit2_LIBRARIES JavaScriptCore WebCore ) Then see if it builds....

That does nothing because WebCore also depends on JavaScriptCore. Also removing JavaScriptCore and WTF from WebCore gets us a link line that lacks both libjavascriptcoregtk-4.0.18.3.2.dylib and libWTFGTK.a. Thus we fail because we need to link against libjavascriptcoregtk-4.0.18.3.2.dylib (but not libWTFGTK). Just removing WTF from WebCore_LIBRARIES doesn't work either. We still end up linking against both. Just removing both JavaScriptCore and WTF from WebCore_LIBRARIES doesn't work either. We still end up linking against both. I can't see how to get the build system to link against libjavascriptcoregtk but not libWTFGTK. cmake drives me crazy...

I'm giving up on trying to beat cmake into submission. Our workaround for now is just to edit link.txt after running cmake. ie: sed -i '' "s|../../lib/libWTFGTK.a||" Source/WebKit2/CMakeFiles/WebKit2.dir/link.txt

Although it looks like I need to do the same for WebKitWebProcess and other places where it's linked in statically.

It looks like this goes well beyond just WTF. Most of the executables are linking against both the dylibs and static archives. For example MiniBrowser is linking libwebkit2gtk-4.0.37.13.0.dylib libjavascriptcoregtk-4.0.18.3.2.dylib libbmalloc.a libWebCoreGTK.a libANGLESupport.a libGObjectDOMBindings.a libWebCorePlatformGTK.a libWTFGTK.a Why does cmake not realize that the functionality provided by those static archives is already rolled into the dylibs that it built? Depending on JavaScriptCore should just result in linking that dylib, not linking that dylib *AND* all the static archives that went into that dylib. Have I mentioned how much I dislike cmake?

(In reply to comment #9) > It looks like this goes well beyond just WTF. Most of the executables are > linking against both the dylibs and static archives. For example > MiniBrowser is linking > > libwebkit2gtk-4.0.37.13.0.dylib > libjavascriptcoregtk-4.0.18.3.2.dylib > libbmalloc.a > libWebCoreGTK.a > libANGLESupport.a > libGObjectDOMBindings.a > libWebCorePlatformGTK.a > libWTFGTK.a > > Why does cmake not realize that the functionality provided by those static > archives is already rolled into the dylibs that it built? Depending on > JavaScriptCore should just result in linking that dylib, not linking that > dylib *AND* all the static archives that went into that dylib. > > Have I mentioned how much I dislike cmake? Clearly we need to figure out what's up here. The static libraries are "convenience libs" which are never installed: they're only there to make reasoning about the build system easier, and so that we can catch layering violations between the libraries. MiniBrowser should only be linking to libwebkit2gtk-4.0.37.13.0.dylib and libjavascriptcoregtk-4.0.18.3.2.dylib. I wonder if the Mac port is having any similar linking problems?

Taking a quick look over https://cmake.org/cmake/help/v3.4/command/target_link_libraries.html I think this might be what the PUBLIC, PRIVATE, and INTERFACE specifiers are for. What if, in Source/JavaScriptCore/CMakeLists.txt, instead of this: target_link_libraries(JavaScriptCore ${JavaScriptCore_LIBRARIES}) You were to replace it with: target_link_libraries(JavaScriptCore PRIVATE ${JavaScriptCore_LIBRARIES}) Perhaps that would fix this? Similarly (for Source/WebKit2/CMakeLists.txt): set(WebKit2_LIBRARIES PRIVATE WebCore INTERFACE JavaScriptCore )

(In reply to comment #11) > set(WebKit2_LIBRARIES > PRIVATE WebCore > INTERFACE JavaScriptCore > ) Hm, putting the visibility specifiers inside the lists is probably not going to work; you might need to split it up into WebKit2_PRIVATE_LIBRARIES, WebKit2_PUBLIC_LIBRARIES, and WebKit2_INTERFACE_LIBRARIES.

*** Bug 153093 has been marked as a duplicate of this bug. ***

Created attachment 273923 [details] Doesn't fix the problem I've been trying to correct this, but have been trying various combinations of PUBLIC, PRIVATE, and INTERFACE all weekend (and waiting most times for WebCore to rebuild, as cmake doesn't seem to be able to determine that all I've changed is the linking libraries). Attached is a work-in-progress patch (not formatted for committing) of what I have now, which doesn't fix the crash. I think the problem is that I don't understand how the various convenience libraries should be linked together. From the other comments here, it seems it should be something like this: WTF -> convenience library, linked into JavaScriptCore -> symbols used from JavaScriptCore, WebCore, and WebKit2 JavaScriptCore -> public, uses and exports WTF symbols WebCore -> convenience library, linked into WebKit2 -> uses WTF and JavaScriptCore symbols -> symbols used from WebKit2 WebKit2 -> public, uses WTF, JavaScriptCore, WebCore symbols I _think_ that's what I've implemented in the patch, but I still end up with JavaScriptCore and WebKit2 each containing their own copy of WTF. Advice would be appreciated.

(In reply to comment #14) > WTF -> convenience library, linked into JavaScriptCore > -> symbols used from JavaScriptCore, WebCore, and WebKit2 > > JavaScriptCore -> public, uses and exports WTF symbols > > WebCore -> convenience library, linked into WebKit2 > -> uses WTF and JavaScriptCore symbols > -> symbols used from WebKit2 > > WebKit2 -> public, uses WTF, JavaScriptCore, WebCore symbols Yes, that's all correct.