Bug 171029 – [AppleWin] The procedure entry point ?waitForThreadCompletion@WTF@@YAHI@Z could not be located in the dynamic link library WebKitQuartzCoreAdditions.dll

• Component: Web Template Framework
• Status: RESOLVED FIXED

[Fujii Hironori]

[AppleWin] The procedure entry point ?waitForThreadCompletion@WTF@@YAHI@Z could not be located in the dynamic link library WebKitQuartzCoreAdditions.dll

AppleWin port debug build trunk@215506
While starting MiniBrowser, a message box is shown.

> The procedure entry point ?waitForThreadCompletion@WTF@@YAHI@Z could not be located in the dynamic link library C:\Program Files (x86)\Common Files\Apple\Apple Application Support\WebKitQuartzCoreAdditions.dll

Pushing its OK button, MiniBrowser seems working fine.
waitForThreadCompletion was removed in Bug 170502.

[Fujii Hironori]

Is Bug 25348 Comment 22 a similar issue?

[Yusuke Suzuki]

Alex, can we update WebKitQuartzCoreAdditions.dll thing?
Or should we leave the binary compatible layer over the new threading mechanism?
It is ok to add such a layere if it is necessary.

[Alex Christensen]

Not sure.  Brent has updated those libraries before.  I haven't.
We could add a stub waitForThreadCompletion for binary compatibility if it's no problem.

[Fujii Hironori]

Created attachment 307960 [details]
dumpbin /imports WebKitQuartzCoreAdditions.dll

Here are the symbols imported from WTF.dll.

[Yusuke Suzuki]

(In reply to Fujii Hironori from comment #4)
> Created attachment 307960 [details]
> dumpbin /imports WebKitQuartzCoreAdditions.dll
> 
> Here are the symbols imported from WTF.dll.

OK, let's create a workaround for Windows.
It seems that we need to have

+ waitForThreadCompletion
+ createThread

Ideally, in the next update, these things should be removed.

[Yusuke Suzuki]

Created attachment 307962 [details]
Patch

[Brent Fulgham]

Yes -- I'll try to get this fixed ASAP. The WebKitQuartzCoreAdditions relies on WTF for some of its threading functions, and after the API was changed they are no longer compatible.

[Brent Fulgham]

Comment on attachment 307962 [details]
Patch

Please, no! Let's just fix the problem.

[Radar WebKit Bug Importer]

<rdar://problem/31789014>

[Brent Fulgham]

Comment on attachment 307962 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=307962&action=review

> Source/WTF/ChangeLog:9
> +        waitForThreadCompletion and createThread. This patch implements the both on the top of the new APIs.

This patch implements BOTH ON TOP of the new APIs.

> Source/WTF/wtf/ThreadHolder.cpp:-53
> -        threadSpecificSet(m_key, new ThreadHolder(thread));

Let's keep this ugly:
#if !OS(WINDOWS)
threadSpecificSet ...
#else
// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed.

> Source/WTF/wtf/ThreadHolder.cpp:55
> +        platformInitialize(holder);

#endif

> Source/WTF/wtf/ThreadHolder.h:78
> +    static void platformInitialize(ThreadHolder*);

I think this should be "#if OS(WINDOWS)", too.

> Source/WTF/wtf/ThreadHolderPthreads.cpp:52
> +}

Remove this whole thing.

> Source/WTF/wtf/ThreadHolderWin.cpp:72
>  

Add a comment:

"// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed."

> Source/WTF/wtf/Threading.h:219
> +// https://bugs.webkit.org/show_bug.cgi?id=171029

Remove this Bugzilla bug, since this is the bug where the workaround was added.

Instead, say: "// Remove this workaround code when <rdar://problem/31793213> is fixed."

> Source/WTF/wtf/ThreadingWin.cpp:514
>  

Add a comment:

"// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed."

[Brent Fulgham]

I looked into it, and I can't fix this as easily as I had hoped, since WebKitQuartzCoreAdditions is installed with Apple Software, not with our own development Zip file.

So, we have to keep this backwards-compatibility code until new Apple software rolls out externally.

So I'm approving your patch, but would like you to add some comments to remind us to remove this when the relevant code ships.

[Yusuke Suzuki]

Comment on attachment 307962 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=307962&action=review

OK, thanks!

>> Source/WTF/ChangeLog:9
>> +        waitForThreadCompletion and createThread. This patch implements the both on the top of the new APIs.
> 
> This patch implements BOTH ON TOP of the new APIs.

Fixed.

>> Source/WTF/wtf/ThreadHolder.cpp:-53
>> -        threadSpecificSet(m_key, new ThreadHolder(thread));
> 
> Let's keep this ugly:
> #if !OS(WINDOWS)
> threadSpecificSet ...
> #else
> // FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed.

Fixed.

>> Source/WTF/wtf/ThreadHolder.cpp:55
>> +        platformInitialize(holder);
> 
> #endif

Fixed.

>> Source/WTF/wtf/ThreadHolder.h:78
>> +    static void platformInitialize(ThreadHolder*);
> 
> I think this should be "#if OS(WINDOWS)", too.

Fixed.

>> Source/WTF/wtf/ThreadHolderPthreads.cpp:52
>> +}
> 
> Remove this whole thing.

OK, dropped.

>> Source/WTF/wtf/ThreadHolderWin.cpp:72
>>  
> 
> Add a comment:
> 
> "// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed."

Added.

>> Source/WTF/wtf/Threading.h:219
>> +// https://bugs.webkit.org/show_bug.cgi?id=171029
> 
> Remove this Bugzilla bug, since this is the bug where the workaround was added.
> 
> Instead, say: "// Remove this workaround code when <rdar://problem/31793213> is fixed."

OK, fixed this part!

>> Source/WTF/wtf/ThreadingWin.cpp:514
>>  
> 
> Add a comment:
> 
> "// FIXME: Remove this workaround code once <rdar://problem/31793213> is fixed."

Added.

[Yusuke Suzuki]

Created attachment 308045 [details]
Patch

[Yusuke Suzuki]

Committed r215713: <http://trac.webkit.org/changeset/215713>

[Yusuke Suzuki]

Hi, now, one year later, can we remove this workaround?