I've been looking into bug 27036 http://bugs.winehq.org/show_bug.cgi?id=27036 , and it's due to the lack of thread safety by default in libgcrypt (in this case via libgnutls in secur32.dll). To be thread safe, libgcrypt requires a call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt initialization is done. However, libgcrypt is used by a lot of different libs, one of which is being used by some other dll that's loading before secur32.dll.
My question is, is it acceptable to do the gcry_control() call in ntdll's DllMain()? The alternative seems to be tracking down every lib used by wine that uses libgcrypt and doing it in each of those dlls. What's the best way to handle this?
On Wed, Feb 08, 2012 at 02:48:06PM -0600, Adam Martinson wrote:
I've been looking into bug 27036 http://bugs.winehq.org/show_bug.cgi?id=27036 , and it's due to the lack of thread safety by default in libgcrypt (in this case via libgnutls in secur32.dll). To be thread safe, libgcrypt requires a call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt initialization is done. However, libgcrypt is used by a lot of different libs, one of which is being used by some other dll that's loading before secur32.dll.
My question is, is it acceptable to do the gcry_control() call in ntdll's DllMain()? The alternative seems to be tracking down every lib used by wine that uses libgcrypt and doing it in each of those dlls. What's the best way to handle this?
No, this would break abstraction.
Why is libgcrypt needed here? It does not seem to be linked directly by any Wine component, also it seems strange that gnutls pulls it in...
Can you call it on DllMain() on secur32.dll?
Ciao, Marcus
On Wed, Feb 8, 2012 at 1:56 PM, Marcus Meissner marcus@jet.franken.de wrote:
On Wed, Feb 08, 2012 at 02:48:06PM -0600, Adam Martinson wrote:
I've been looking into bug 27036 http://bugs.winehq.org/show_bug.cgi?id=27036 , and it's due to the lack of thread safety by default in libgcrypt (in this case via libgnutls in secur32.dll). To be thread safe, libgcrypt requires a call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt initialization is done. However, libgcrypt is used by a lot of different libs, one of which is being used by some other dll that's loading before secur32.dll.
My question is, is it acceptable to do the gcry_control() call in ntdll's DllMain()? The alternative seems to be tracking down every lib used by wine that uses libgcrypt and doing it in each of those dlls. What's the best way to handle this?
No, this would break abstraction.
Why is libgcrypt needed here? It does not seem to be linked directly by any Wine component, also it seems strange that gnutls pulls it in...
Can you call it on DllMain() on secur32.dll?
Ciao, Marcus
I don't know the exact details, but libgcrypt and gnutls are related. If you search for "gnutls thread safety", you'll find information like this:
http://www.manpagez.com/info/gnutls/gnutls-2.10.4/gnutls_64.php
http://www.gnupg.org/documentation/manuals/gcrypt/Multi_002dThreading.html
-
Adam Martinson -
Lei Zhang -
Marcus Meissner