[gpgme] fork() problem

[Marcus Brinkmann]

At Sun, 18 Feb 2007 13:00:12 +0100,
Stephan Menzel <smenzel at gmx-gmbh.de> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; iso-8859-1 (quoted-printable)>]
> Hi Marcus,
> 
> thanks for your response.
> I'm already about to get crazy debugging this. ;-)

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.

You may want to try different optimization levels.  At least one stack
trace looked bogus (the lock null pointer).

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.

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

Do you do funky stuff with signals?

Maybe this gives you some ideas.  I know how difficult these problems
are to track down, but it is impossible to do it "remotely" and with
almost no knowledge about the application and environment you are
working with, so I can only stab in the dark here.

Thanks,
Marcus