Public bug reported:
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:
[EMAIL PROTECTED] > 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.
** Affects: openssl (Ubuntu)
Importance: Untriaged
Status: Unconfirmed
--
SSL_library_init allocates memory that cannot be de-allocated
https://launchpad.net/bugs/60021
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
