On Mon, Jul 02, 2001 at 08:54:15AM -0700, Travis Vitek wrote:
> The following testcase occasionally fails on several different systems
> (quite often on hp11 with a moderate load) when a thread attempts to release
> a mutex which it doesn't own via the locking callback. I am using debugging
> mutexes to expose the problem; most code I've seen use fast or normal
> mutexes (the default) and never check the result of the mutex lock/unlock
> operations...
I recently found and (hopefully) fixed a bug matching this
description, but did not have multi-threaded software for actually
testing it:
*) In crypto/rand/md_rand.c, replace 'add_do_not_lock' flag by a
combination of a flag and a thread ID variable.
Otherwise while one thread is in ssleay_rand_bytes (which sets the
flag), *other* threads can enter ssleay_add_bytes without obeying
the CRYPTO_LOCK_RAND lock (and may even illegaly release the lock
that they do not hold after the first thread unsets add_do_not_lock).
[Bodo Moeller]
Please try the latest 0.9.6-stable snapshot (ftp://ftp.openssl.org/snapshot/)
and report if the problem has been solved.
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
