openssl memory leak: me or bug?
Multi tool use
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
Post as a guest
P,r4I,PvZdp8ZgiQqDdUX GKgc6WBjfNbxKtq2i,JyGWI,7x0,cPzup CzykBP7
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