Bug#399904: gnupg: --list-keys hangs at ctrl-C
On Fri, 12 Jul 2013 07:34, gni...@fsij.org said: Attached is a fix. It works for me. Looks fine. Please push. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#399904: gnupg: --list-keys hangs at ctrl-C
On 2013-07-12 at 10:16 +0200, Werner Koch wrote: Looks fine. Please push. Thanks. Pushed. Also, I updated the bug tracker report at bugs.g10code.com. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#399904: gnupg: --list-keys hangs at ctrl-C
This is follow up to the bug #399904 in Debian. It is now assigned to libc6, but I think that this would be a bug of GnuPG 1.4.x. The call sequence in question is: g10/signal.c:got_fatal_signal - util/dotlock.c:dotlock_remove_lockfiles - util/dotlock.c:dotlock_destroy - free Here, free is not a one of async-signal-safe functions (see: signal(7) ). When the signal handler is called interrupting malloc or related, hang might occur. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#399904: gnupg: --list-keys hangs at ctrl-C
On Thu, 11 Jul 2013 10:43, gni...@fsij.org said: Here, free is not a one of async-signal-safe functions (see: signal(7) ). When the signal handler is called interrupting malloc or related, hang might occur. Argh. A fix for that would be a function which sets a flag in the dotlock module to skip all async functions. We can't do it directly because the cleanup is dones via atexit. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#399904: gnupg: --list-keys hangs at ctrl-C
I could reproduce this bug on wheezy environment (x86_64-linux-gnu).
I got the backtrace. It was indeed 'malloc' interrupted by
signal, and signal_handler called 'free'.
Attached is a fix. It works for me.
(gdb) bt
#0 0x7fb7c9aab4cb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fb7c9a416b8 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x7fb7c9a3faa1 in free () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x004a6e7b in dotlock_destroy_unix (h=0x2274080) at
../../util/dotlock.c:890
#4 dotlock_destroy (h=0x2274080) at ../../util/dotlock.c:941
#5 0x004a6ed8 in dotlock_remove_lockfiles () at
../../util/dotlock.c:1304
#6 0x0042f8ae in got_fatal_signal (sig=1) at ../../g10/signal.c:125
#7 signal handler called
#8 0x7fb7c9a3d348 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#9 0x7fb7c9a3fb90 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x004a2688 in xmalloc (n=n@entry=256) at ../../util/memory.c:443
#11 0x0049c25a in mpi_alloc_limb_space (nlimbs=nlimbs@entry=32,
secure=optimized out) at ../../mpi/mpiutil.c:146
#12 0x0049c0e2 in mpihelp_mul_karatsuba_case (prodp=0x2499470,
up=0x2467420, usize=16, vp=0x2467420, vsize=vsize@entry=16,
ctx=ctx@entry=0x7fff618a97f0) at ../../mpi/mpih-mul.c:388
#13 0x0049bd92 in mpihelp_mul (prodp=prodp@entry=0x2499470,
up=up@entry=0x2467420, usize=usize@entry=16, vp=vp@entry=0x2467420,
vsize=vsize@entry=16) at ../../mpi/mpih-mul.c:522
#14 0x004986ea in mpi_mul (w=0x246c280, u=optimized out, v=optimized
out) at ../../mpi/mpi-mul.c:187
#15 0x004988b9 in mpi_mulm (w=0x246c280, u=optimized out,
v=optimized out, m=0x23a2340) at ../../mpi/mpi-mul.c:211
#16 0x00499568 in mpi_mulpowm (res=0x246c140, basearray=0x7fff618a99a0,
exparray=optimized out, m=0x23a2340) at ../../mpi/mpi-mpow.c:71
#17 0x0048b703 in verify (pkey=0x7fff618a9a20, hash=0x23b6110,
s=0x25081c0, r=0x2508130) at ../../cipher/dsa.c:349
#18 verify (r=0x2508130, s=0x25081c0, hash=0x23b6110, pkey=0x7fff618a9a20) at
../../cipher/dsa.c:318
#19 0x0048c0e0 in dsa_verify (algo=optimized out, hash=optimized
out, data=optimized out, pkey=optimized out) at ../../cipher/dsa.c:457
#20 0x0042a9fb in do_check (ret_pk=0x0, digest=0x227d7f0,
sig=0x2508050, pk=0x244d230, r_expired=optimized out, r_revoked=optimized
out) at ../../g10/sig-check.c:293
#21 do_check (pk=0x244d230, sig=0x2508050, digest=0x227d7f0,
r_expired=optimized out, r_revoked=optimized out, ret_pk=0x0) at
../../g10/sig-check.c:237
#22 0x0042b705 in check_key_signature2 (root=root@entry=0x24b2350,
node=node@entry=0x2456cb0, check_pk=check_pk@entry=0x0,
ret_pk=ret_pk@entry=0x0, is_selfsig=is_selfsig@entry=0x0,
r_expiredate=r_expiredate@entry=0x0, r_expired=r_expired@entry=0x0) at
../../g10/sig-check.c:640
#23 0x0042b97b in check_key_signature (root=root@entry=0x24b2350,
node=node@entry=0x2456cb0, is_selfsig=is_selfsig@entry=0x0) at
../../g10/sig-check.c:499
#24 0x00410531 in merge_selfsigs_main (rinfo=0x7fff618a9bd0,
r_revoked=synthetic pointer, keyblock=optimized out) at
../../g10/getkey.c:1838
#25 merge_selfsigs (keyblock=optimized out) at ../../g10/getkey.c:2319
#26 merge_selfsigs (keyblock=optimized out) at ../../g10/getkey.c:2298
#27 0x004138fc in merge_keys_and_selfsig (keyblock=optimized out) at
../../g10/getkey.c:1385
#28 0x0042f0a2 in list_all (secret=secret@entry=0) at
../../g10/keylist.c:446
#29 0x0042f5cb in public_key_list (list=0x0) at ../../g10/keylist.c:107
#30 0x00408f5c in main (argc=0, argv=0x7fff618aa288) at
../../g10/gpg.c:3633
--
diff --git a/g10/gpgv.c b/g10/gpgv.c
index 9ee8032..2d51829 100644
--- a/g10/gpgv.c
+++ b/g10/gpgv.c
@@ -434,7 +434,7 @@ void rl_free_line_state (void) {}
void dotlock_disable(void) {}
dotlock_t dotlock_create (const char *file_to_lock, unsigned int flags)
{ return NULL; }
-void dotlock_destroy (dotlock_t h) {}
+void dotlock_destroy (dotlock_t h, int reclaim) {}
int dotlock_take (dotlock_t h, long timeout) { return 0;}
int dotlock_release (dotlock_t h) {return 0;}
-void dotlock_remove_lockfiles (void) {}
+void dotlock_remove_lockfiles (void, int reclaim) {}
diff --git a/g10/keydb.c b/g10/keydb.c
index d6d83e2..8be1945 100644
--- a/g10/keydb.c
+++ b/g10/keydb.c
@@ -181,7 +181,7 @@ maybe_create_keyring (char *filename, int force)
if (lockhd)
{
dotlock_release (lockhd);
- dotlock_destroy (lockhd);
+ dotlock_destroy (lockhd, 1);
}
return rc;
}
diff --git a/g10/signal.c b/g10/signal.c
index 086bf51..44b863d 100644
--- a/g10/signal.c
+++ b/g10/signal.c
@@ -122,7 +122,7 @@ got_fatal_signal( int sig )
/* Reset action to default action and raise signal again. */
init_one_signal (sig, SIG_DFL, 0);
-dotlock_remove_lockfiles ();
+dotlock_remove_lockfiles (0);
#ifdef __riscos__
riscos_close_fds ();
#endif /* __riscos__ */
diff --git
Bug#399904: gnupg: --list-keys hangs at ctrl-C
found 399904 2.13-37
thanks
On 2006-11-23 09:39:23 +0100, Werner Koch wrote:
I was able to duplicate this after some tries. strace shows that it
hangs in
futex(0xb7ea9880, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call)
I can also reproduce this bug, with the same example.
The strace ends with:
[...]
21935 write(1, sub 4096R/F4958D46 2012-02-10\n, 32) = 32
21935 write(1, \n, 1) = 1
21935 getrusage(RUSAGE_SELF, {ru_utime={0, 768048}, ru_stime={0, 40002}, ...})
= 0
21935 times({tms_utime=76, tms_stime=4, tms_cutime=0, tms_cstime=0}) =
1828252106
21935 lseek(6, 0, SEEK_SET) = 0
21935 lseek(6, 2153824, SEEK_SET) = 2153824
21935 read(6,
\231\1\242\4F!9\1\21\4\0\226\225\217\307\\BL\266+\37\270\34\0-Z\245\374\371\3373...,
8192) = 8192
21935 read(6,
f\304B\17L\266B\277\311\1\231\210F\4\20\21\2\0\6\5\2Fq\204\374\0\n\t\0205\326\254...,
8192) = 8192
21935 --- SIGINT (Interrupt) @ 0 (0) ---
21935 munmap(0x7f5fe36c1000, 32768) = 0
21935 write(2, \n, 1) = 1
21935 write(2, gpg, 3)= 3
21935 write(2, : , 2) = 2
21935 write(2, Interrupt, 9) = 9
21935 write(2, caught ... exiting\n, 20) = 20
21935 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f5fe24c34f0}, NULL, 8)
= 0
21935 unlink(/home/vinc17/.gnupg/.#lk0x124feb0.xvii.21935) = 0
21935 futex(0x7f5fe2816e60, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be
restarted)
21935 --- SIGQUIT (Quit) @ 0 (0) ---
21935 tgkill(21935, 21935, SIGQUIT) = 0
[...]
My machine has:
gnupg 1.4.12-6
libc6 2.13-37
Linux xvii 3.5-trunk-amd64 #1 SMP Debian 3.5.5-1~experimental.1 x86_64 GNU/Linux
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#399904: gnupg: --list-keys hangs at ctrl-C
Hi! I was able to duplicate this after some tries. strace shows that it hangs in futex(0xb7ea9880, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call) The EINTR is due to the SIGQUIT. I am running Sid using the same glibc version but a stock gpg 1.4.5. A quick check of the glibc 2.4 source shows that the futex syscall is only used within the nptl library (according to file names). gpg is a single-threaded application so the cause must be somewhere in glibc or in the crt. Trying to run under strace or ltrace does not show the problem. Salam-Shalom, Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399904: gnupg: --list-keys hangs at ctrl-C
Architecture: amd64 (x86_64) Well, I am running on i386 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64 Stock Linux 2.6.15.2 (not the Debioan package) Shalom-Salam, Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399904: gnupg: --list-keys hangs at ctrl-C
Package: gnupg Version: 1.4.5-2 Severity: minor hi the command $ gpg --list-keys has a very long output , so I tried to stop it by ctrl-C ; then this prints 'gpg: Interrupt caught ... exiting' but sometimes though and then the gpg process hangs and does not exit(and must be killed) to reproduce it in a safe way , I tried with $ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg --list-keys and I can reproduce it a. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (450, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Versions of packages gnupg depends on: ii gpgv1.4.5-2 GNU privacy guard - signature veri ii libbz2-1.0 1.0.3-6 high-quality block-sorting file co ii libc6 2.3.6.ds1-7 GNU C Library: Shared libraries ii libldap22.1.30-13+b1 OpenLDAP libraries ii libreadline55.2-1GNU readline and history libraries ii libusb-0.1-42:0.1.12-2 userspace USB programming library ii makedev 2.3.1-83 creates device files in /dev ii zlib1g 1:1.2.3-13 compression library - runtime gnupg recommends no packages. -- no debconf information -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
