New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not released memory if legacy provider or own library context is used. #16516
Comments
|
@t8m OPENSSL_init_crypto(0, NULL); does not help (reply to irc question :) I also tried own atexit call with OPENSSL_cleanup() and some leaks are still there. |
|
I do not think this is a release blocker but OTC should look at this. |
|
OTC: not a blocker for 3.0.0 |
|
To not forget, some findings:
|
|
Could you test this against 3.0? |
|
@mbroz could it be that you're loading legacy.so from the Debian build given the paths you've configured? Could you strace the reproducer to verify? |
I tested everything against 3.0 branch (on yesterday's git) - I am pretty sure that the issue was there. @t8m well, I did that mistake in the beginning :) But now I have Debian without any openssl3 files (purged everything) and I use just "make install" from the devel git (it only requires Debianish paths for Config) - so it is loading the devel-compiled legacy.so. I'll try strace. |
|
For openssl-3.0 branch configured with I get this strace: And I verified that /usr/lib/x86_64-linux-gnu/ossl-modules/legacy.so is installed with make install form openssl tree. |
I am able to reproduce this with @paulidale - please note that you need these options to see the leaks. There are basically two kinds of leaks - one from the initialization done inside the cleanup - probably should be fixed by doing initialization in OSSL_PROVIDER_load() and OSSL_LIB_CTX_new(). And then there are the shared library associated leaks which are eliminated when |
|
Something weird is going on: even with those valgrind options, I'm not seing the problem... |
|
@paulidale And the legacy provider successfully loads for you? |
|
Ah, that's the issue -- the load fails. With the environment set up properly, I see the leaks. |
|
Please try #16558 |
Yes, it fixes all the leaks (except remaining 4 related to DSO load - I guess this is just side effect of not using no-pinshared). Thanks! |
|
While #16558 has not been merged... any plans to fix this issue with a different approach? |
Hi,
we have to use legacy provider in libcryptsetup and when running under valgrind, a lot of still-in-use memory is reported.
I reproduced it with current openssl-3.0 branch on Debian, configured and installed just as
and this simple C standalone reproducer:
Running under valgrind, I see
What is wrong here? Shouldn't it release all context and provider used memory?
Full valgrind log:
The text was updated successfully, but these errors were encountered: