openssl memory leak: me or bug?
up vote
4
down vote
favorite
Trying to parse info from certificates using openssl (1.0.2p) , can't make it leak-free. Code:
std::ifstream fst("2048b-rsa-example-cert.der", std::ios::binary);
std::vector<std::uint8_t> certificate((std::istreambuf_iterator<char>(fst)),
std::istreambuf_iterator<char>() );
const std::uint8_t* data = certificate.data();
X509 *info = d2i_X509(nullptr, &data, certificate.size());
X509_free(info);
Certificate examples:http://fm4dd.com/openssl/certexamples.htm
The biggest leak traceback:
==20846== at 0x4C2EEAF: malloc (vg_replace_malloc.c:299)
==20846== by 0x52380E7: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51BDF2F: lh_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239484: ex_data_check (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239544: def_get_class (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239FBA: int_new_ex_data (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51DE8D3: x509_cb (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E28F8: asn1_item_ex_combine_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E55E8: asn1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E6224: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E627A: ASN1_item_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x109199: main (ssl.cpp:48)
platform: Linux
OpenSSL 1.0.2p 14 Aug 2018
built on: reproducible build, date unspecified
platform: linux-x86_64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: x86_64-pc-linux-gnu-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -O2 -pipe -march=native -fno-strict-aliasing -Wa,--noexecstack
OPENSSLDIR: "/etc/ssl"
c++ memory-leaks openssl
asked Nov 8 at 9:58
serafean
656
add a comment |
up vote
4
down vote
favorite
Trying to parse info from certificates using openssl (1.0.2p) , can't make it leak-free. Code:
std::ifstream fst("2048b-rsa-example-cert.der", std::ios::binary);
std::vector<std::uint8_t> certificate((std::istreambuf_iterator<char>(fst)),
std::istreambuf_iterator<char>() );
const std::uint8_t* data = certificate.data();
X509 *info = d2i_X509(nullptr, &data, certificate.size());
X509_free(info);
Certificate examples:http://fm4dd.com/openssl/certexamples.htm
The biggest leak traceback:
==20846== at 0x4C2EEAF: malloc (vg_replace_malloc.c:299)
==20846== by 0x52380E7: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51BDF2F: lh_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239484: ex_data_check (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239544: def_get_class (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239FBA: int_new_ex_data (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51DE8D3: x509_cb (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E28F8: asn1_item_ex_combine_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E55E8: asn1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E6224: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E627A: ASN1_item_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x109199: main (ssl.cpp:48)
platform: Linux
OpenSSL 1.0.2p 14 Aug 2018
built on: reproducible build, date unspecified
platform: linux-x86_64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: x86_64-pc-linux-gnu-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -O2 -pipe -march=native -fno-strict-aliasing -Wa,--noexecstack
OPENSSLDIR: "/etc/ssl"
c++ memory-leaks openssl
asked Nov 8 at 9:58
serafean
656
Gonna need some platform information. I just hammered this out on osx (high sierra) running 1.0.2l (yeah, its a bit old; sry) and no such leak exhibits. edit: upgraded to 1.0.2p; still no leak (Valgrind-3.14.0).
– WhozCraig
Nov 8 at 10:14
edited: Added platform info.
– serafean
Nov 8 at 10:28
Are you sure it isn't some library buffer which isn't going to be freed at all? That is, does the leak grow?
– hyde
Nov 8 at 10:33
yes, it grows with every d2i_X509/X509_free combo.
– serafean
Nov 8 at 10:50
scratch that, had a bad pointer, it doens't grow. Might indeed be a library buffer...
– serafean
Nov 8 at 10:51
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
Trying to parse info from certificates using openssl (1.0.2p) , can't make it leak-free. Code:
std::ifstream fst("2048b-rsa-example-cert.der", std::ios::binary);
std::vector<std::uint8_t> certificate((std::istreambuf_iterator<char>(fst)),
std::istreambuf_iterator<char>() );
const std::uint8_t* data = certificate.data();
X509 *info = d2i_X509(nullptr, &data, certificate.size());
X509_free(info);
Certificate examples:http://fm4dd.com/openssl/certexamples.htm
The biggest leak traceback:
==20846== at 0x4C2EEAF: malloc (vg_replace_malloc.c:299)
==20846== by 0x52380E7: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51BDF2F: lh_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239484: ex_data_check (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239544: def_get_class (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239FBA: int_new_ex_data (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51DE8D3: x509_cb (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E28F8: asn1_item_ex_combine_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E55E8: asn1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E6224: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E627A: ASN1_item_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x109199: main (ssl.cpp:48)
platform: Linux
OpenSSL 1.0.2p 14 Aug 2018
built on: reproducible build, date unspecified
platform: linux-x86_64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: x86_64-pc-linux-gnu-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -O2 -pipe -march=native -fno-strict-aliasing -Wa,--noexecstack
OPENSSLDIR: "/etc/ssl"
c++ memory-leaks openssl
asked Nov 8 at 9:58
serafean
656
Trying to parse info from certificates using openssl (1.0.2p) , can't make it leak-free. Code:
std::ifstream fst("2048b-rsa-example-cert.der", std::ios::binary);
std::vector<std::uint8_t> certificate((std::istreambuf_iterator<char>(fst)),
std::istreambuf_iterator<char>() );
const std::uint8_t* data = certificate.data();
X509 *info = d2i_X509(nullptr, &data, certificate.size());
X509_free(info);
Certificate examples:http://fm4dd.com/openssl/certexamples.htm
The biggest leak traceback:
==20846== at 0x4C2EEAF: malloc (vg_replace_malloc.c:299)
==20846== by 0x52380E7: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51BDF2F: lh_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239484: ex_data_check (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239544: def_get_class (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x5239FBA: int_new_ex_data (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51DE8D3: x509_cb (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E28F8: asn1_item_ex_combine_new (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E55E8: asn1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E6224: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x51E627A: ASN1_item_d2i (in /usr/lib64/libcrypto.so.1.0.0)
==20846== by 0x109199: main (ssl.cpp:48)
platform: Linux
OpenSSL 1.0.2p 14 Aug 2018
built on: reproducible build, date unspecified
platform: linux-x86_64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: x86_64-pc-linux-gnu-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -O2 -pipe -march=native -fno-strict-aliasing -Wa,--noexecstack
OPENSSLDIR: "/etc/ssl"
c++ memory-leaks openssl
c++ memory-leaks openssl
asked Nov 8 at 9:58
serafean
656
asked Nov 8 at 9:58
serafean
656
edited Nov 8 at 10:27
asked Nov 8 at 9:58
serafean
656
asked Nov 8 at 9:58
serafean
656
asked Nov 8 at 9:58
serafean
656
656
Gonna need some platform information. I just hammered this out on osx (high sierra) running 1.0.2l (yeah, its a bit old; sry) and no such leak exhibits. edit: upgraded to 1.0.2p; still no leak (Valgrind-3.14.0).
– WhozCraig
Nov 8 at 10:14
edited: Added platform info.
– serafean
Nov 8 at 10:28
Are you sure it isn't some library buffer which isn't going to be freed at all? That is, does the leak grow?
– hyde
Nov 8 at 10:33
yes, it grows with every d2i_X509/X509_free combo.
– serafean
Nov 8 at 10:50
scratch that, had a bad pointer, it doens't grow. Might indeed be a library buffer...
– serafean
Nov 8 at 10:51
add a comment |
Gonna need some platform information. I just hammered this out on osx (high sierra) running 1.0.2l (yeah, its a bit old; sry) and no such leak exhibits. edit: upgraded to 1.0.2p; still no leak (Valgrind-3.14.0).
– WhozCraig
Nov 8 at 10:14
edited: Added platform info.
– serafean
Nov 8 at 10:28
Are you sure it isn't some library buffer which isn't going to be freed at all? That is, does the leak grow?
– hyde
Nov 8 at 10:33
yes, it grows with every d2i_X509/X509_free combo.
– serafean
Nov 8 at 10:50
scratch that, had a bad pointer, it doens't grow. Might indeed be a library buffer...
– serafean
Nov 8 at 10:51
Gonna need some platform information. I just hammered this out on osx (high sierra) running 1.0.2l (yeah, its a bit old; sry) and no such leak exhibits. edit: upgraded to 1.0.2p; still no leak (Valgrind-3.14.0).
– WhozCraig
Nov 8 at 10:14
Gonna need some platform information. I just hammered this out on osx (high sierra) running 1.0.2l (yeah, its a bit old; sry) and no such leak exhibits. edit: upgraded to 1.0.2p; still no leak (Valgrind-3.14.0).
– WhozCraig
Nov 8 at 10:14
edited: Added platform info.
– serafean
Nov 8 at 10:28
edited: Added platform info.
– serafean
Nov 8 at 10:28
Are you sure it isn't some library buffer which isn't going to be freed at all? That is, does the leak grow?
– hyde
Nov 8 at 10:33
Are you sure it isn't some library buffer which isn't going to be freed at all? That is, does the leak grow?
– hyde
Nov 8 at 10:33
yes, it grows with every d2i_X509/X509_free combo.
– serafean
Nov 8 at 10:50
yes, it grows with every d2i_X509/X509_free combo.
– serafean
Nov 8 at 10:50
scratch that, had a bad pointer, it doens't grow. Might indeed be a library buffer...
– serafean
Nov 8 at 10:51
scratch that, had a bad pointer, it doens't grow. Might indeed be a library buffer...
– serafean
Nov 8 at 10:51
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
The OpenSSL Library Initialization wiki provides a list of functions that you might need to invoke to properly clean up the library. As far as I can tell, the bytes/blocks mentioned in your traceback are not leaked, but they are still in use at exit -- you did not provide all output though.
For this snippet, it looks like adding
CRYPTO_cleanup_all_ex_data();
at the end does the trick. Running it with valgrind with flags --leak-check=full --show-leak-kinds=all shows that the amount of "in use at exit" goes down from 416 bytes in 6 blocks to 0 bytes in 0 blocks.
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
The OpenSSL Library Initialization wiki provides a list of functions that you might need to invoke to properly clean up the library. As far as I can tell, the bytes/blocks mentioned in your traceback are not leaked, but they are still in use at exit -- you did not provide all output though.
For this snippet, it looks like adding
CRYPTO_cleanup_all_ex_data();
at the end does the trick. Running it with valgrind with flags --leak-check=full --show-leak-kinds=all shows that the amount of "in use at exit" goes down from 416 bytes in 6 blocks to 0 bytes in 0 blocks.
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
add a comment |
up vote
0
down vote
The OpenSSL Library Initialization wiki provides a list of functions that you might need to invoke to properly clean up the library. As far as I can tell, the bytes/blocks mentioned in your traceback are not leaked, but they are still in use at exit -- you did not provide all output though.
For this snippet, it looks like adding
CRYPTO_cleanup_all_ex_data();
at the end does the trick. Running it with valgrind with flags --leak-check=full --show-leak-kinds=all shows that the amount of "in use at exit" goes down from 416 bytes in 6 blocks to 0 bytes in 0 blocks.
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
add a comment |
up vote
0
down vote
up vote
0
down vote
The OpenSSL Library Initialization wiki provides a list of functions that you might need to invoke to properly clean up the library. As far as I can tell, the bytes/blocks mentioned in your traceback are not leaked, but they are still in use at exit -- you did not provide all output though.
For this snippet, it looks like adding
CRYPTO_cleanup_all_ex_data();
at the end does the trick. Running it with valgrind with flags --leak-check=full --show-leak-kinds=all shows that the amount of "in use at exit" goes down from 416 bytes in 6 blocks to 0 bytes in 0 blocks.
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
The OpenSSL Library Initialization wiki provides a list of functions that you might need to invoke to properly clean up the library. As far as I can tell, the bytes/blocks mentioned in your traceback are not leaked, but they are still in use at exit -- you did not provide all output though.
For this snippet, it looks like adding
CRYPTO_cleanup_all_ex_data();
at the end does the trick. Running it with valgrind with flags --leak-check=full --show-leak-kinds=all shows that the amount of "in use at exit" goes down from 416 bytes in 6 blocks to 0 bytes in 0 blocks.
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
edited Nov 9 at 0:02
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
answered Nov 8 at 23:51
Reinier Torenbeek
8,93722845
8,93722845
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53205318%2fopenssl-memory-leak-me-or-bug%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Gonna need some platform information. I just hammered this out on osx (high sierra) running 1.0.2l (yeah, its a bit old; sry) and no such leak exhibits. edit: upgraded to 1.0.2p; still no leak (Valgrind-3.14.0).
– WhozCraig
Nov 8 at 10:14
edited: Added platform info.
– serafean
Nov 8 at 10:28
Are you sure it isn't some library buffer which isn't going to be freed at all? That is, does the leak grow?
– hyde
Nov 8 at 10:33
yes, it grows with every d2i_X509/X509_free combo.
– serafean
Nov 8 at 10:50
scratch that, had a bad pointer, it doens't grow. Might indeed be a library buffer...
– serafean
Nov 8 at 10:51