SSL_library_init allocates memory that cannot be de-allocated

[Erik de Castro Lopo]

Binary package hint: openssl

Here's a simple test program:

#include <stdio.h>

#include <openssl/ssl.h>
#include <openssl/err.h>

int
main (int argc, char **argv __attribute__ ((unused)))
{
 SSL_library_init () ;
 return 0 ;
}

Compiling and running this under valgrind results in:

erikd@honshu > valgrind --leak-check=yes --show-reachable=yes ./ssl_memleak
==4828== Memcheck, a memory error detector.
==4828== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==4828== Using LibVEX rev 1471, a library for dynamic binary translation.
==4828== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==4828== Using valgrind-3.1.0-Debian, a dynamic binary instrumentation framework.
==4828== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==4828== For more details, rerun with: -v
==4828==
--4828-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--4828-- DWARF2 CFI reader: unhandled CFI instruction 0:50
==4828==
==4828== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
==4828== malloc/free: in use at exit: 1,336 bytes in 81 blocks.
==4828== malloc/free: 83 allocs, 2 frees, 1,416 bytes allocated.
==4828== For counts of detected errors, rerun with: -v
==4828== searching for pointers to 81 not-freed blocks.
==4828== checked 257,176 bytes.
==4828==
==4828== 128 bytes in 1 blocks are still reachable in loss record 1 of 2
==4828== at 0x401D89D: realloc (vg_replace_malloc.c:306)
==4828== by 0x40AA0E4: ??? (mem.c:86)
==4828== by 0x40AA812: CRYPTO_realloc (mem.c:331)
==4828== by 0x4113BEC: lh_insert (lhash.c:341)
==4828== by 0x40ADAC4: OBJ_NAME_add (o_names.c:203)
==4828== by 0x411C26D: EVP_add_digest (names.c:81)
==4828== by 0x4069DA5: SSL_library_init (ssl_algs.c:99)
==4828== by 0x80485D0: main (in /home/erikd/Proj/bCodeSender/ssl_memleak)
==4828==
==4828==
==4828== 1,208 bytes in 80 blocks are still reachable in loss record 2 of 2
==4828== at 0x401C422: malloc (vg_replace_malloc.c:149)
==4828== by 0x40AA0AD: ??? (mem.c:79)
==4828== by 0x40AA728: CRYPTO_malloc (mem.c:304)
==4828== by 0x4113638: lh_new (lhash.c:119)
==4828== by 0x40AD69A: OBJ_NAME_init (o_names.c:53)
==4828== by 0x40ADB64: OBJ_NAME_add (o_names.c:186)
==4828== by 0x411C1F8: EVP_add_cipher (names.c:69)
==4828== by 0x4069CA5: SSL_library_init (ssl_algs.c:68)
==4828== by 0x80485D0: main (in /home/erikd/test/ssl_memleak)
==4828==
==4828== LEAK SUMMARY:
==4828== definitely lost: 0 bytes in 0 blocks.
==4828== possibly lost: 0 bytes in 0 blocks.
==4828== still reachable: 1,336 bytes in 81 blocks.
==4828== suppressed: 0 bytes in 0 blocks.

The problem here is that if one is searching for memory leaks in one's own code, the SSL leaks make my leaks harder to find.

It looks like this SSL library needs a function like SSL_library_release()
so that SSL_library_init() followed by SSL_library_realeaser() would result in zero valgrind errors.

[Paul Dufresne (paulduf)]

Well, what you describe is already answered in openssl FAQ:
http://www.openssl.org/support/faq.html#PROG13

However, a long discussion thread exist on:
http://<email address hidden>/msg22434.html
And I did not read it all. And don't really feel like to.

Does this answer your bug report?

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.