[gpgme] fork() problem

[Stephan Menzel]

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 different optimization levels.  At least one stack
> trace looked bogus (the lock null pointer).

I think they are. I often get stuff like that in the coredumps and yes, it 
mostly happens due to optimization. Unfortunatley, it's not easy to do this 
unoptimized since I would have to deploy it live to see the error and this 
might prove a bit tricky but I'll see what I can do.

> 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.

> With your wrapper class which serializes all GPGME invocations, you
> can do something nifty: You can keep a trace of all GPGME invocations
> in a log file, with stacktraces at time of invocation.  With a bit of
> hacking (making GPGME's engine_info_lock variable global and export it
> in the symbols file) you can also check before and after each
> invocation what the value of the PRIVATE member of the
> engine_info_lock semaphore structure is.  It must be a (void *) 0
> (unlocked state).

Well, I see if I can find time for this. Couldn't promise it though.

> Do you do funky stuff with signals?

No.

But I'll see what I can do to provide further info.

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/20070221/f39beadc/attachment.pgp