Max, Glad you reached to the bottom of the problem. In my case - after carefully analyzing the "e_chil.c" engine initialization code and my own application code - it turned out to be an extremely trivial issue.
The "disable_mutex_callbacks" is by default initialized to 0, thus if you do not 'mistakenly' set it to 1 by using the THREAD_LOCKING command before engine initialization, OpenSSL will automatically detect the dynamic locking callback functions and use them appropriately. What I discovered quickly is that my application code was simply setting callback functions after the CHIL engine was already initialized and thus during callback function check in engine init. (e_chil.c): "CRYPTO_get_dynlock_create_callback()", "CRYPTO_get_dynlock_lock_callback()" and "CRYPTO_get_dynlock_destroy_callback" were simply getting NULL - ahhh, how come I could not have spotted this obvious thing any sooner :). >From a common application developepment perspective, it would be nice to have >a warning message whereby if the thread locking is enabled >(disable_mutex_callbacks = 0) and callbacks are NOT set (irrelevant whether >static or dynamic) in a correct sequence, a warning should be generated. A >patch with a single error line would do the trick here I think. Thanks, P.M. ----- Original Message ----- From: "Max Pala" <[EMAIL PROTECTED]> To: "OpenSSL Users" <openssl-users@openssl.org> Sent: Friday, November 21, 2008 8:41 PM Subject: FIXED - CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500) Hi Sander, I debugged the init process and it seems that you were right. The disable_mutex_callbacks is set to 1 at e_chil.c:578. Definitely it is due to initialization, at this point... ... looked into that, and... et voilas! Found the problem! The PRE commands were wrong. Indeed the following: 5.engine_pre = THREAD_LOCKING:1 caused the disable_mutex_callbacks to be set to 1, therefore no callbacks were used! Ahhhh... what a nightmare! If you want to be sure, you can set it to 0: 5.engine_pre = THREAD_LOCKING:0 Przemek, this should solve also your problem - so you can enable multiple threads and get rid of your 'lock' around the signing function. I think that the config variable should have been called: DISABLE_THREAD_LOCKING because if THREAD_LOCKING is set to 1 - then the disable_mutex_callbacks is set to 1.. which should be the contrary (developer's error ?). Very confusing... and besides, it should give out some warning!!! Anyhow, now the callbacks are called, and the server seems to run pretty ok with a relatively large amount of threads (150). But I still have to stress-test it... Thanks to all of you who helped me - now I have a single file with the code for OpenSSL and pthreads, both static and dynamic locks.. Shall we include it into OpenSSL ? void OpenSSL_pthread_init( void ); .. that would make it more usable for the average developer! :D Later, Max Sander Temme wrote: > > On Nov 21, 2008, at 8:50 AM, Max Pala wrote: > >> The problem is that they are not called by the nCipher driver - no sign >> at all in the logs... :( How come they are not called ??? > > > Can you set a breakpoint in engines/e_chil.c:581 and inspect the value > of disable_mutex_callbacks? It should be 0 and if it isn't, libnfhwcrhk > never learns about the existence of the locks. > > S. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
