On Thu, Nov 08, 2007, Jeff Johnson wrote:

> While I'm not at all worried about the memory leaks from openssl
> initialization, I am tired of seeing same old, same old using valgrind:
>
> ==21087== 4,672 bytes in 3 blocks are still reachable in loss record 3 of 4
> ==21087==    at 0x4805622: realloc (vg_replace_malloc.c:306)
> ==21087==    by 0xB4A784: (within /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xB4AEB6: CRYPTO_realloc (in /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA5AF6: lh_insert (in /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA85BD: (within /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA7D2D: (within /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBE2181: ERR_load_X509V3_strings (in
> /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA97C9: ERR_load_crypto_strings (in
> /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0x1FA956: SSL_load_error_strings (in /lib/libssl.so.0.9.8b)
> ==21087==    by 0x4B44690: (within /usr/lib/libneon.so.27.0.2)
> ==21087==    by 0x4B3C12F: ne_sock_init (in /usr/lib/libneon.so.27.0.2)
> ==21087==    by 0x494B23D: davInit (rpmdav.c:388)
> ==21087==
> ==21087==
> ==21087== 25,944 bytes in 2,084 blocks are still reachable in loss record 4
> of 4
> ==21087==    at 0x4805525: malloc (vg_replace_malloc.c:149)
> ==21087==    by 0xB4A74D: (within /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xB4ADCE: CRYPTO_malloc (in /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA5B5F: lh_insert (in /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA85BD: (within /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA7D2D: (within /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA9575: ERR_load_ERR_strings (in
> /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0xBA977A: ERR_load_crypto_strings (in
> /lib/libcrypto.so.0.9.8b)
> ==21087==    by 0x1FA956: SSL_load_error_strings (in /lib/libssl.so.0.9.8b)
> ==21087==    by 0x4B44690: (within /usr/lib/libneon.so.27.0.2)
> ==21087==    by 0x4B3C12F: ne_sock_init (in /usr/lib/libneon.so.27.0.2)
> ==21087==    by 0x494B23D: davInit (rpmdav.c:388)
>
> What's the best way to get rid of these leaks? I understand perfectly
> why a neon library cannot eliminate the leaks, see the comments in
> ne_sock_init.

Can't RPM just call OpenSSL's ERR_free_strings() explicitly itself in
case it knows it is using NEON (we provide "WITH_NEON") and NEON is
using SSL (<ne_utils.h> provides "NE_FEATURE_SSL")?

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com