We should be able to test this by calling ERR_peek_error() or ERR_get_error() in a test build in production to see if they are picking up any errors that haven’t been cleared.
-Bryan > On Sep 26, 2017, at 8:05 AM, Sudheer Vinukonda <[email protected]> > wrote: > > Just to add some more context related to this - > > IIRC, the patch proposed below (to clear the error queue only when an error > occurred) was actually how this fix was implemented when it was first added > (sometime during 5.3?) However, I think it was still resulting in some > unexplained handshake/connect failures (which turned out to be not exactly > connect failures, but were being marked so, due to stale error queue). And > that was when the fix was changed to clear the error queue *before* calling > connect. > > All of this being a few years and releases ago, may no longer be the case and > assuming the reordering of the clear queue tests good with no handshake > failures or other side affects, this fix sounds fine. > > - Sudheer > > > > I agree this needs to be tested > >> On Sep 26, 2017, at 7:51 AM, Leif Hedstrom <[email protected]> wrote: >> >> >>> On Sep 21, 2017, at 8:55 PM, [email protected] wrote: >>> >>> With the patch, the ERR_clear_error() will only be called when the error >>> occurs. In the normal situation, ERR_clear_error() will not be called, so >>> the Err_get_state() will not be called and no lock contention in openssl >>> 1.0.1 with the patch. >>> >>> >>> ----- 原始邮件 ----- >>> 发件人：Bryan Call <[email protected]> >>> 收件人：[email protected] >>> 抄送人：users <[email protected]> >>> 主题：Re: Openssl 1.1.0f Support >>> 日期：2017年09月21日 23点37分 >>> >>> This only changes the order of the calls. There is still going to be lock >>> contention inside OpenSSL 1.0.1. >>> >>> -Bryan >> >> >> I think this makes a lot of sense (but I haven’t tested it). Did you make a >> PR for this on Github? >> >> Cheers, >> >> — leif >> >
