[gpgme] fork() problem
smenzel at gmx-gmbh.de
Wed Feb 21 08:50:00 CET 2007
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.
there are several platforms. All of them running debian with kernels ranging
from 2.6.16 up to 2.6.18
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
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.
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
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
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
==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
==5676== by 0x4BCAF94: gpgme_get_key
==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?
But I'll see what I can do to provide further info.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070221/f39beadc/attachment.pgp
More information about the Gnupg-devel