GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for bugfix

[Stefan Haller]

Hi

No timeout, you're right. I failed to read the code properly...

I used truss to generate some output. Please find it attached. Search for 
the term "signal".

Hope this helps...
 Stefan



Stefan Haller
Software Development
Transport Revenue
________________________________ 
Ascom Autelca Ltd.
Worbstrasse 201
CH-3073 Gümligen 
Phone 
Fax 
+41 31 999 65 06
+41 31 999 65 82 
stefan.haller at ascom.ch
www.ascom.com





Werner Koch <wk at gnupg.org>
Sent by: gnupg-devel-bounces at gnupg.org
13/08/04 11:30

 
        To:     gnupg-devel at gnupg.org
        cc: 
        Subject:        Re: GPG Lockfile (concurrency) issue, keyring lost: awarding 300$ for 
bugfix


On Fri, 13 Aug 2004 09:38:44 +0200, Stefan Haller said:

> Werner, your patch works great for me. I'm especially happy with the 
fact 
> that I do not need to consider the lock-exit code thanks to your 10 
second 
> timeout...

Hmmm, there is no timeout.

> I have only two questions, is there a good reason that I get the 
following 
> message :
> gpg: some signal caught ... exiting

Your system does not define NSIG so there is no proper way to print
the signal name from within a signal handler.

> I got this message 20 times during the period that is required to import 

> 50 keys... But exit code seems to be 0 always and I cannot spot any real 

> problem with it.

If it is possible for you too have it run under strace or truss we
might be able to figure out what signal causes the problem.

Probably it will also work to modify the following function in
g10/signal.c to read:

static const char *
get_signal_name( int signum )
{
#if defined(SYS_SIGLIST_DECLARED) && defined(NSIG)
    return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?";
#else
    /*return "some signal";*/
    static char buf[100];
    sprintf (buf, "signal no %d ", signum);
    return buf;
#endif
}

> Second question, are you going to include this patch in the development 
> branch that is used for the next stable release?

I'll do a release candidate for 1.2.6 today (unless your signal
problem is serious) including the patch.  This is also to test the new
gettext version we decided to use for 1.2.6.


  Werner


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: truss.log.gz
Type: application/octet-stream
Size: 44108 bytes
Desc: not available
Url : /pipermail/attachments/20040813/39f9efea/truss.log-0001.exe