On 08/29/2018 10:49 AM, Christophe Jaillet wrote:
> Ok, it is trickier than I thought.
>
> On 2018/08/29 07:55:04, Ruediger Pluem wrote:
>>
>> 2. As the error handling is a stack I think it is a valid use case for
>> another consumer of openssl to check for the
>>error later and not
Ok, it is trickier than I thought.
On 2018/08/29 07:55:04, Ruediger Pluem wrote:
>
> 2. As the error handling is a stack I think it is a valid use case for
> another consumer of openssl to check for the
>error later and not directly like e.g. with errno.
>
but in this case, haven't we
On 08/29/2018 09:37 AM, Christophe Jaillet wrote:
> Pure speculation:
>
> Actually we ERR_clear_error unconditionally so that in case of error, we can
> safely call SSL_get_error.
>
> Doc says:
> << >>
> ERR_get_error() returns the earliest error code from the thread's error
Pure speculation:
Actually we ERR_clear_error unconditionally so that in case of error, we can
safely call SSL_get_error.
Doc says:
<< >>
ERR_get_error() returns the earliest error code from the thread's error queue
and removes the entry. This function can be called repeatedly
Having a brief look at ERR_clear_error in openssl it looks like that various
locking operations are performed to get the
error state. I assume that this causes a lot of contention in the load case.
The question is whether there is another solution to BZ62590 but to call
ERR_clear_error before
I guess it would be helpful to know which openssl version was used for the
test. There was a valid use case for BZ62590
and the question is why ERR_clear_error is that expensive. But the
expensiveness might depend on the used openssl version.
Regards
Rüdiger
On 08/28/2018 04:54 PM, William A
Hello,
On 2018-08-28 10:54, William A Rowe Jr wrote:
> As we unwind various regressions and breakage, one non-lethal but
> somewhat horrid report stands out. Eric correctly tied it to the patch
> applied for https://bz.apache.org/bugzilla/show_bug.cgi?id=62590 in the
> 2.4.24 timeframe.
I'd like
As we unwind various regressions and breakage, one non-lethal but somewhat
horrid report stands out. Eric correctly tied it to the patch applied for
https://bz.apache.org/bugzilla/show_bug.cgi?id=62590 in the 2.4.24
timeframe.
Server Software:Apache/2.2.34
SSL/TLS Protocol:
