From: Bill Rebey <[EMAIL PROTECTED]>
Bill.Rebey> The problem appears to be (from visual inspection - I
Bill.Rebey> didn't try to watch thread_hash in a debugger) that
Bill.Rebey> ERR_remove_state (crypto/err/err.c) interrogates
Bill.Rebey> thread_hash without a Lock. I'm guessing that at the top
Bill.Rebey> of the function, thread_hash is non-null, but since the
Bill.Rebey> function isn't Locking its access to thread_hash, by the
Bill.Rebey> time it gets around to calling lh_delete, thread_hash is,
Bill.Rebey> in fact, NULL, and we blow up in lh_delete.
[...]
Bill.Rebey> Does anyone agree or disagree that the first version is
Bill.Rebey> wrong, and is the source of my crashes, and that the
Bill.Rebey> second version solves the problem?
You're assesment is correct, there's a potential race condition there.
I've now entered a changed that almost mirrors your change. What I
did was just to wrap the original code between the lock and the unlock
with a 'if (thread_hash) { ... }'. I've kept the first check of
thread_hash and the assignment of pid as it was, since that's not
sensitive to race conditions (as far as I can see at least).
Thanks for finding this glitch.
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
