wolfssl: clean up wolfcrypt error queue#7594
wolfssl: clean up wolfcrypt error queue#7594a5ehren wants to merge 1 commit intocurl:masterfrom a5ehren:wolfssl_leak
Conversation
If wolfSSL is built in certain ways (OPENSSL_EXTRA or Debug), the error queue gets added on to for each session and never freed. Fix it by calling ERR_clear_error() like in vtls/openssl when needed. This func is a no-op in wolfcrypt if the error queue is not enabled.
|
Are you saying that there's some kind of memory leak without this patch, or what exactly is the problem this addresses? |
|
Yeah, but there is only a leak if Wolf is built a certain way (max Openssl compatibility) and there are errors in the SSL_read/write paths. This patch just makes curl treat the Wolfssl error queue the same way as the OpenSSL one - if it isn’t needed due to Wolf being built normally, the Clear function here is a no-op. |
|
But why does it have to clear it all the time? If the OpenSSL code does that it seems like a mistake not worth repeating here. Shouldn't the error queue rather get cleared when the connection closes? |
|
That’s a good question. I’ll poke at the code and see if these others actually matter. |
|
So the call before every SSL_read/write comes from this commit 11 years ago: a0dd9df Apparently the error stack is shared across all callers of the library, so the extra calls to ERR_clear_error() are to guard against bad behavior in other libraries not cleaning up after themselves and causing cURL to abort the connection instead of returning EAGAIN for non-blocking sockets. |
|
Thanks for that research and answer to the question. So let's stick to this model for now. |
|
Thanks! |
If wolfSSL is built in certain ways (OPENSSL_EXTRA or Debug), the error
queue gets added on to for each session and never freed. Fix it by
calling ERR_clear_error() like in vtls/openssl when needed. This func
is a no-op in wolfcrypt if the error queue is not enabled.