[gnutls-dev] Memory leeks?

[Simon Posnjak]

V pet, 27.08.2004 ob 10:57 je Werner Koch napisal(a):
> On Fri, 27 Aug 2004 01:24:00 +0200, Simon Posnjak said:
> 
> > checked it for memory leeks with valgrind i discovered that gnutls
> > (libgrypt) seams to be leaking. My HTTP server dose not leek (when I
> 
> I presume you are using libgcrypt 1.2.0.  Would you mind to use the
> CVS version (-r LIBGCRYPT-1-2-BRANCH would be best, but HEAD should
> alos do). It is at :pserver:anoncvs at cvs.gnupg.org:/cvs/gnupg (password
> is "anoncvs").
> 
> We fixed a couple of memory leaks since the last release.

Sorry, I was a bit tired (been writing the mail at 1 am) and forget to
write down the versions of my library. They are:
libgpg-error-1.0.tar.bz2
libgcrypt-1.2.0.tar.bz2
gnutls-1.0.20.tar.bz2

OK, next: I checked out LIBGCRYPT-1-2-BRANCH and HEAD revisions from
CVS, tried them and discovered that there is no change. Still leaking
almost the same amount of memory in almost the same way:

==28765== malloc/free: in use at exit: 2206 bytes in 37 blocks.
==28765== malloc/free: 17348 allocs, 17311 frees, 2503586 bytes
allocated.
==28765==
==28765== searching for pointers to 37 not-freed blocks.
==28765== checked 4411420 bytes.
==28765==
==28765==
==28765== 62 bytes in 1 blocks are definitely lost in loss record 1 of 4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x806B91F: generate_rdn_seq (in
/stuff1/delo/carneol-cpot/carneol/blocks/http_server_block/tests/simple_web_server_tls/simple_http_tls)
==28765==    by 0x806C9E1: gnutls_certificate_set_x509_trust_file (in
/stuff1/delo/carneol-cpot/carneol/blocks/http_server_block/tests/simple_web_server_tls/simple_http_tls)
==28765==    by 0x804A3C2: thread_http (thread_http.c:82)
==28765==
==28765==
==28765== 144 bytes in 6 blocks are still reachable in loss record 2 of
4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x8049FA2: gcry_pthread_mutex_init (thread_http.c:23)
==28765==    by 0x808DCA7: _gcry_ath_init (ath.c:67)
==28765==    by 0x808AA5E: global_init (global.c:67)
==28765==
==28765==
==28765== 672 bytes in 28 blocks are still reachable in loss record 3 of
4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x808A67E: _gcry_malloc (global.c:404)
==28765==    by 0x808A80B: gcry_malloc (global.c:420)
==28765==    by 0x80B0C3A: _gcry_module_add (module.c:76)
==28765==
==28765==
==28765== 1328 bytes in 2 blocks are still reachable in loss record 4 of
4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x808A673: _gcry_malloc (global.c:402)
==28765==    by 0x808A80B: gcry_malloc (global.c:420)
==28765==    by 0x808A830: gcry_xmalloc (global.c:547)


I attached a patch to make LIBGCRYPT-1-2-BRANCH compile and all so in
the HEAD revision there is no mpi.c file in tests directory - you have
to edit Makefile.am to make it compile.

As I understand this output, the still reachable blocks mean that you
have a live pointer to the occupied memory, but you did not release it.
Whats fun about it is that if I run my http_server in a thread and stop
that thread (doing TLS cleanup) and then start it again (initing TLS
again) the still reachable memory stays the same - the lost memory
(generate_rdn_seq) doubles. So I think (and please correct me if I am
wrong) that this still reachable memory is libgcypt global state or some
thing like that - it would be nice if there would be a function to free
this stuff. (I am on a embedded platform with 16 MB of RAM and every
byte counts;).

The only "real" memory leak seams to be in generate_rdn_seq function,
but looking at the code I can not find it - everything looks fine to me.

Thank you.

		Regards Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgcrypt-1.2.0-cvs.diff
Type: text/x-patch
Size: 1454 bytes
Desc: not available
Url : /pipermail/attachments/20040827/3f77e336/libgcrypt-1.2.0-cvs.bin