Quick scan of code leads to this:
e_chil.c:
if (disable_mutex_callbacks == 0)
{
if (CRYPTO_get_dynlock_create_callback() != NULL &&
CRYPTO_get_dynlock_lock_callback() != NULL &&
CRYPTO_get_dynlock_destroy_callback() != NULL)
{
hwcrhk_globals.mutex_init = hwcrhk_mutex_init;
hwcrhk_globals.mutex_acquire = hwcrhk_mutex_lock;
hwcrhk_globals.mutex_release = hwcrhk_mutex_unlock;
hwcrhk_globals.mutex_destroy = hwcrhk_mutex_destroy;
}
so disable_mutex_callbacks should be zero and those functions set.
This code is called, in the end, from
ENGINE_load_chil()
so that call should happen at the start/init phase of the app or you
won't get those mutex_* funcs set.
The dyn lock id is determined in the function hwcrhk_mutex_init() (see
e_chil.c for that one as well), which will be called from inside some
CHIL code (non-OpenSSL code) as that function is registered with CHIL
through that hwcrhk_globals global callback set by having it passed
into the CHIL API hook p_hwcrhk_Init() which _should_ point at
libnfhwcrhk.so/nfhwcrhk.dll's HWCryptoHook_Init().
I'd say: take e_chil.c and augment it with extra logging calls OR
trace it through with a debugger so you can see if those mutex_*
functions are (a) set up in that global structure at all and (b) if
the mutex_init gets called at all after that. Too many spots where you
can have a booboo due to some little detail missing.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [EMAIL PROTECTED]
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
