[gpgme] fork() problem

[Stephan Menzel]

Am Mittwoch, 21. Februar 2007 23:32:12 schrieb Marcus Brinkmann:
> You may want to try to compile your own glibc with NPTL.  From what I
> have heard, NPTL is more standard conform to pthread than
> linuxthreads.  Of course, that's just more stabbing in the dark, but
> it's worth it because it really is a completely different
> implementation.

Yeah.
We did that, I just forgot to call the right executable. Instead of 
/lib/libc.so.6
one should call
/lib/tls/libc.so.6 which says:

GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-13).
Compiled on a Linux 2.6.0-test7 system on 2006-09-06.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        NPTL 0.60 by Ulrich Drepper
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
Report bugs using the `glibcbug' script to <bugs at gnu.org>.

so we do have and use NPTL which is confirmed.

> > ==5676== 2,088 (96 direct, 1,992 indirect) bytes in 2 blocks are
> > definitely lost in loss record 93 of 146
> > ==5676==    at 0x40207E3: calloc
> > (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> > ==5676==    by 0x4BCA6FC: (within /usr/lib/libgpgme-pthread.so.11.6.2)
> > ==5676==    by 0x4BCB7C0: (within /usr/lib/libgpgme-pthread.so.11.6.2)
> > ==5676==    by 0x4BD3B1C: (within /usr/lib/libgpgme-pthread.so.11.6.2)
> > ==5676==    by 0x4BC5D2D: (within /usr/lib/libgpgme-pthread.so.11.6.2)
> > ==5676==    by 0x4BC687D: (within /usr/lib/libgpgme-pthread.so.11.6.2)
> > ==5676==    by 0x4BCAE34: gpgme_op_keylist_next
> > (in /usr/lib/libgpgme-pthread.so.11.6.2)
> > ==5676==    by 0x4BCAF94: gpgme_get_key
> > (in /usr/lib/libgpgme-pthread.so.11.6.2)
> > ==5676==    by 0x4BAFC21: MyClass::getKey(char const*) (MyClass.cc:39)
> >
> > I'll try to find out if I was causing the leak here.
>
> Maybe you don't release a key acquired with gpgme_get_key with
> gpgme_key_unref?

Ooops. I didn't know such a function exists :-(
I always thought calling gpgme_release on the context clears all the buffers 
used within the session.
I'll fix this, thanks for the hint.

Greetings...

Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070301/a4d9bde2/attachment.pgp