[gpgme] fork() problem

[Marcus Brinkmann]

At Wed, 21 Feb 2007 08:50:00 +0100,
Stephan Menzel <smenzel at gmx-gmbh.de> wrote:
> 
> Am Mittwoch, 21. Februar 2007 02:06:08 schrieb Marcus Brinkmann:
> > It would be good to have some information about the platform you are
> > using, in particular which Linux kernel version and which glibc
> > library version, and if you are using Linux threads or the NPTL
> > pthread package.  Even if it doesn't help us now it may be useful
> > information later when other stumble over similar issues.
> 
> Hi Marcus,
> 
> there are several platforms. All of them running debian with kernels ranging 
> from 2.6.16 up to 2.6.18
> 
> libc says:
> 
> sm at box:~> /lib/libc.so.6
> 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
>         linuxthreads-0.10 by Xavier Leroy
>         BIND-8.2.3-T5B
>         libthread_db work sponsored by Alpha Processor Inc
>         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>.
> 
> And we are using pthreads.

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.
 
> > It's always worth it to run valgrind on a program just to make sure
> > there is no memory corruption which messes everything up for good of
> > course.
> 
> We do this on a regular base. The daemon is as far as I know free of memleaks.
> I just tried a little run locally here and indeed I found two little things in 
> gpgme related parts:
> 
> ==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?

Thanks,
Marcus