Have observed a similar problem despite the fact the nCipher patch is applied
and crypto locks (both static and dynamic) are set. Have never properly
investigated it so perhaps now is the time...
I checked this with two versions of OpenSSL 0.9.8h (without nCipher patch and
with the patch).
BTW - the most part of the patch is that it adds support for static locks.
My application has also all necessary dynamic as well as static crypto locks
setup.
scenario 1:
- without nCipher patch
- without my own static mutex around signing operation
- result: application aborts and the nCipher CHIL client library generates an
error:
../client.c:762: receive: Assertion `!!(((void)"multiple threads active, but no
synchronization upcalls", u.app->mutexcreateupcall))' failed.
(also some times the nfast server fails to respond or at least this is the
error message that I am getting from time to time from the CHIL client library)
scenario 2:
- without nCipher patch
- with my own static mutex around signing operation
- result: everything works well with many threads however in fact only single
thread accesses the device at a time (which is not really ideal but in the same
way does not greatly reduce the performance)
scenario 3:
- with nCipher patch
- without my own static mutex around signing operation
- result: application aborts (abort signal) but no library error is generated
this time
scenario 4:
- with nCipher patch
- with my own static mutex around signing operation
- result: everything works well with many threads however in fact only single
thread accesses the device at a time
While debugging the application, I can see static crypto locks being used but
the dynamic ones not.
P.M.
----- Original Message -----
From: "Max Pala" <[EMAIL PROTECTED]>
To: <openssl-users@openssl.org>
Sent: Friday, November 21, 2008 5:50 PM
Subject: Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hi Geoff,
I actually tried the same approach, I had a small test function that I call
at the start of each thread that initializes, locks, unlocks and destroys
the dyn locks.. and the functions are properly called.
unsigned long lock, lock2 = 0;
printf("About to test\n");
lock = CRYPTO_get_new_dynlockid();
lock2 = CRYPTO_get_new_dynlockid();
printf("Got new locks %lu, %lu\n", lock, lock2);
CRYPTO_w_lock(lock);
printf("Locked the lock\n");
CRYPTO_w_unlock(lock);
printf("Unlocked the lock\n");
CRYPTO_destroy_dynlockid(lock);
CRYPTO_destroy_dynlockid(lock2);
printf("Destroyed the locks, DONE\n");
the result, for each new thread is:
Got new locks 4294967283, 4294967295
Locked the lock
Unlocked the lock
Destroyed the locks, DONE
and in the logs, the functions properly log the start and end of each _dyn_
function, that is:
...
Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_create_callback() start
Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_create_callback() stop
Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_lock_callback() start
Nov 21 17:36:19 ncipher168 ocspd[26357]: _dyn_lock_callback() end
...
Therefore it seems that the callbacks are properly registered!
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 ???
Later,
Max
Geoff Thorpe wrote:
> On Friday 21 November 2008 03:01:33 Massimiliano Pala wrote:
>> Hi David,
>>
>> that is really nice.. although.. after I gave it a try... it does not
>> really work :(
>>
>> Actually, it seems that the dynamic functions are never called... :(
>>
>> Investigating...
>
> The attached example seems to work. I put it in the top-level directory
> of the (built) openssl tree and compiled with;
> gcc -Wall -Iinclude -o foobar foobar.c -L. -lcrypto
>
> The output shows that dynamic lockids are negative;
> About to test
> Created lock 'dyn_lck.c:257'
> Created lock 'dyn_lck.c:257'
> Got new locks -1, -2
> Doing mode 9 lock on 'dyn_lck.c:257' from foobar.c:47
> Locked the lock
> Doing mode 10 lock on 'dyn_lck.c:257' from foobar.c:49
> Unlocked the lock
> Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329
> Destroying lock 'dyn_lck.c:257' from dyn_lck.c:329
> Destroyed the locks, DONE
>
> Perhaps that'll help distinguish what's going on in your code?
>
> Cheers,
> Geoff
>
>
______________________________________________________________________
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]
