Some of the control logic in OpenSSL does peek at the thread error queue to decide what caused a lower-level failure. For example, see the code for PEM_bytes_read_bio in pem_lib.c. There are a handful of other files that call ERR_peek_error().
I don't know whether it's documented anywhere, but I'd say yes, it's probably good to drain the error queue each time a thread picks up a new piece of work. This hadn't occurred to me before your note - I'll have to investigate whether any of my code needs to do this as well. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of David Hinkle Sent: Thursday, 14 August, 2014 16:52 To: openssl-users@openssl.org Subject: Error Handling in a Multithreaded Environment, Failures effecting non-associated connections I have a bunch of worker threads that consume a piece of work, deal with that work, and then move on to another piece of work. I've discovered today that if a thread processes a piece of work and a SSL call in that work has an error, and that error isn't consumed with a call to SSL_get_error and ERR_get_error that when the thread pulls the next piece of work a subsequent SSL call can fail. In this particular case, a failure during SSL_accept for one piece of work caused SSL_read to later fail on a unassociated connection being processed by the same thread. I discovered this because I realized after reading through the openssl code that the messages in the error queue didn't make any sense for SSL_read, and when I went back and added the calls to SSL_get_error and ERR_get_error to the SSL_accept call error handling suddenly everything started to work. Is this documented anywhere? Or am I wrong and this shouldn't be happening? -- David Hinkle Senior Software Developer Phone: 800.243.3729x3000 Email: hin...@cipafilter.com<mailto:hin...@cipafilter.com> Hours: Mon-Fri 8:00AM-5:00PM (CT) Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam. This message has been scanned for malware by Websense. www.websense.com
