When using gnupg 2.0.8, I can get exactly one query from the agent: --- PASTE --- PASTE --- PASTE --- PASTE --- jokey@orion8 ~ % keychain 30D5A5B9 && source .keychain/orion8-sh-gpg KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/ Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL * Found existing ssh-agent (8388) * Initializing /home/jokey/.keychain/orion8-sh-gpg file... * Initializing /home/jokey/.keychain/orion8-csh-gpg file... * Initializing /home/jokey/.keychain/orion8-fish-gpg file... * Starting gpg-agent * Adding 1 gpg key(s)... jokey@orion8 ~ % keychain 30D5A5B9 && source .keychain/orion8-sh-gpg KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/ Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL * Found existing ssh-agent (8388) * Found existing gpg-agent (11437) * Adding 1 gpg key(s)... jokey@orion8 ~ % keychain 30D5A5B9 && source .keychain/orion8-sh-gpg KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/ Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL * Found existing ssh-agent (8388) * Initializing /home/jokey/.keychain/orion8-sh-gpg file... * Initializing /home/jokey/.keychain/orion8-csh-gpg file... * Initializing /home/jokey/.keychain/orion8-fish-gpg file... * Starting gpg-agent * Adding 1 gpg key(s)... jokey@orion8 ~ % --- PASTE --- PASTE --- PASTE --- PASTE --- with 2.0.7 it works just fine
Can you reproduce this without keychain? Or add debug log to the ~/.gnupg/gpg-agent.conf, and attach the result?
Works for me... Please provide the debug log of gnupg and gpg-agent. ~/.gnupg/gpg-agent.conf verbose debug-all log-file /tmp/gpg-agent.log ~/.gnupg/gpg.conf debug-all log-file /tmp/gpg.log
Created attachment 140573 [details] gpg-agent.log I was running # keychain --clear and then 4 times (had to enter gpg-password in round 1,2,4) # keychain 072AD062 .ssh/id_dsa
OK... gpg-agent quites... Can you please verify that it is not running after the second add? As nothing in log, I guess some segmentation fault... Can you please run keychain first time, then: gdb -p <gpg-agent-pid> gdb> c And then keychain second time, maybe we know why it quiting. Thanks!
I guess that this doesn't help that much: # gdb -p $(pidof gpg-agent) GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". Attaching to process 14757 Reading symbols from /usr/bin/gpg-agent...Reading symbols from /usr/lib/debug/usr/bin/gpg-agent.debug...done. Using host libthread_db library "/lib/libthread_db.so.1". done. Reading symbols from /usr/lib/libgcrypt.so.11...done. Loaded symbols for /usr/lib/libgcrypt.so.11 Reading symbols from /usr/lib/libgpg-error.so.0...done. Loaded symbols for /usr/lib/libgpg-error.so.0 Reading symbols from /usr/lib/libpth.so.20...done. Loaded symbols for /usr/lib/libpth.so.20 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 0xffffe410 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () The abort signal happens as I start keychain the second time.
confirmed, exactly the same behaviour here
OK. In order to allow upstram to help us... We need to reproduce this without keychain... Try doing the following: In one window: gpg-agent --daemon In second: Paste the output of the gpg-agent, something like: GPG_AGENT_INFO=/tmp/gpg-NO20zc/S.gpg-agent:22901:1; export GPG_AGENT_INFO; Then execute several times: gpg --no-options --use-agent --no-tty --sign --local-user A27B3B1C -o /dev/null /dev/null It should cause the agent to terminate as-well. In gdb when signal received, please also type: gdb> bt apply all threads Thanks!
Created attachment 140599 [details] gpg-agent.strace.log It also happens by using gpg-agent directly - as you described. The backtrace doesn't look very useful (your proposed gdb line didn't work): (gdb) thread apply all bt full (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d7dd81 in raise () from /lib/libc.so.6 #2 0xb7d7f5a8 in abort () from /lib/libc.so.6 #3 0xb7db5bcb in ?? () from /lib/libc.so.6 #4 0x00000007 in ?? () #5 0x08097b50 in ?? () #6 0x00000400 in ?? () #7 0x00000000 in ?? () (gdb) bt full #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7d7dd81 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7d7f5a8 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7db5bcb in ?? () from /lib/libc.so.6 No symbol table info available. #4 0x00000007 in ?? () No symbol table info available. #5 0x08097b50 in ?? () No symbol table info available. #6 0x00000400 in ?? () No symbol table info available. #7 0x00000000 in ?? () No symbol table info available. attached is the strace output of the second run. interesting line: writev(2, [{"*** glibc detected *** ", 23}, {"gpg-agent", 9}, {": ", 2}, {"double free or corruption (out)", 31}, {": 0x", 4}, {"0809f5e0", 8}, {" ***\n", 5}], 7) = 82
Thanks! Please paste emerge --info
app-crypt/gnupg-2.0.8 USE="bzip2 nls -doc -ldap -openct -pcsc-lite (-selinux) -smartcard" Portage 2.1.4_rc14 (default-linux/x86/2007.0/desktop, gcc-4.2.2, glibc-2.7-r1, 2.6.24-rc7 i686) ================================================================= System uname: 2.6.24-rc7 i686 Intel(R) Pentium(R) M processor 1600MHz Timestamp of tree: Wed, 09 Jan 2008 13:30:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.3 dev-lang/python: 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0_rc6-r1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3.9/env /usr/kde/3.9/share/config /usr/kde/3.9/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium-m -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner" FEATURES="collision-protect cvs digest distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms sign strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ http://gentoo.inode.at/" LANG="en_GB.utf8" LC_ALL="en_GB.utf8" LINGUAS="en de en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/mozilla /usr/portage/local/layman/kde" SYNC="rsync://192.168.2.1/gentoo-portage" USE="X a52 aac acpi alsa apache2 avahi berkdb bidi bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups curl dbus divx divx4linux dri dts dvd dvdr dvdread eds emboss encode evo exif fam ffmpeg firefox flac fortran gdbm gif gnome gpm graphviz gs gstreamer gtk hal iconv ieee1394 ipod ipv6 isdnlog java jpeg kde kdeenablefinal kerberos latex lcms live mad midi mikmod mmx mono mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin ntfs ogg oggvorbis openexr opengl openmp oss pam pcre pdf perl png pppd pulseaudio python qt qt3 qt3support qt4 quicktime readline real reflection ruby samba screen sdl session spell spl sse sse2 ssl stream svg tcpd tetex tex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs wxwindows x86 xcomposite xine xinerama xml xorg xprint xulrunner xv xvid zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev synaptics mouse keyboard" KERNEL="linux" LINGUAS="en de en_GB" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Please also paste the output of: echo gnupg libksba libassuan libgcrypt lib-gpgerror pth | xargs -n1 equery --quiet list Thanks!
OK... Upstream request: FEATURES="nostrip" CFLAGS="-g" emerge --oneshot gnupg Then resproduce using strace, and take the address (0x0809f5e0) in previous strace, and run: addr2line -e /usr/bin/gpg-agent <address>
(In reply to comment #11) > echo gnupg libksba libassuan libgcrypt lib-gpgerror pth | xargs -n1 equery > --quiet list [I--] [ ~] app-crypt/gnupg-2.0.8 (0) [I--] [ ] dev-libs/libksba-1.0.2-r1 (0) [I--] [ ~] dev-libs/libassuan-1.0.4 (0) [I--] [ ~] dev-libs/libgcrypt-1.4.0-r1 (0) [I--] [ ] dev-libs/libpthread-stubs-0.1 (0) [I--] [ ~] dev-libs/pth-2.0.7 (0) (In reply to comment #12) > Upstream request: > FEATURES="nostrip" CFLAGS="-g" emerge --oneshot gnupg > > Then resproduce using strace, and take the address (0x0809f5e0) in previous > strace, and run: > > addr2line -e /usr/bin/gpg-agent <address> # addr2line -e /usr/bin/gpg-agent 0809f5e0 ??:0
I tried to run this under valgrind, I got so many errors with this application, that I cannot determine what belongs to this issue. I hope someone from upstream that cares about the quality of his application, will start working on this and not just write tasks on the mailing list.
Hmmm, so... how about masking this version? 2.0.7 works just fine.
Could not believe my eyes! On 1/11/08, Werner Koch <wk@gnupg.org> wrote: > On Thu, 10 Jan 2008 15:22, alon.barlev@gmail.com said: > > > I can... However it is best if you add your self as CC and communicate > > directly with the users. > > If you want to report a bug, pleade use the gnupg bug tracker and don't > point to specifc distribution related one. And please take me out of > the CC from the gentoo bug tracker - all these BTS status messages are > meanigless to me.q Instead of "Thank you for reporting this issue", we get procedural statement... As if upstream cannot open its own bug report in its repository. Communicating directly with people that can reproduce the issue, is irrelevant... Also this bug is meaningless... Nothing here relates to gnupg... Removing Werner from CC as requested. Masking this package.
Unfortunately the gpg agent from gnupg-2.0.7 seems to be very unstable for me, too. I don't know if it is related to this bug, because I have found no way to reproduce the crash reliably. Sometimes the agent just works, sometimes it crashes after the first query and sometimes it crashes after three or four queries. My first try was to recompile gnupg without any optimizations, but this did not help. I will try to narrow down the circumstances under which the crashes occur. Should I open a new bug for this?
Yes, please open a new bug. Try to strace it as done in this bug, maybe some useful information will come out.
Hello, Can reproduce this after pth bump? Thanks!
No response from anyone reproducing the bug since 3 weeks.... Maybe someone who can still reproduce it could write a simple test case like a shell script which reproduces this bug in in (even in freshly created user account without any keys present). This script can then be sent upstream for people to verify and it makes it possible to debug the issue by other people than the reporters. Reporters: Please write a test case! Gentoo people: When it's there, please put it in the upstream bugtracker and announce the newly created bug tracker on the mailing list. It does not matter much whether the test case uses keychain or not, because keychain is just a shell script, so it can't be responsible for a memory allocation error itself. Shell scripts are often part of test cases. Generally: Please do distribution-specific talking in the distribution-specific bugtracker but put everything which is not distribution specific into the upstream bugtracker: There has to be be a central place where bug which affect an upstream package can be traced, and it can only be the upstream bug tracker, and you should be able to create the upstream bug entry yourself. Upstream core maintainers should be able to concentrate on coding and bug fixing and should be getting test cases which demonstrate bugs, not learn how specific distributions work or to solve problems of individual users, it's all about test cases. gpg has a 'make check' which we run it after each 'make' of GnuPG and abort the build if it fails: GPG's make check triggered an error which showed with gcc4.3, and only the test case which triggered it allowed me to see the issue at all, to fix it and send the fix upstream. The bug was actually in libksba and the fix is in the libksba svn now. Test cases do not care where the bug is, they ensure that the tested software works for this test case, which is the goal. Your test case could be converted into a gnupg test case and serve to improve the reliability of gpg-agent when it is included upstream (which is in the interest of upstream maintainers and also distributions).
Working again with 2.0.9 :)
