I noticed this when I started having issues authenticating with gnupg as if the password was wrong. Managed to isolate this to pinentry. When running on a terminal the backtrace linked is produced. If I run the same inside gdb I cannot cause it to crash as it behaves normally. I also tried recompiling with debug symbols (FEATURE=nostrip) but the backtrace produced didn't became more informative. Attachment linked from bug 552614 https://bugs.gentoo.org/attachment.cgi?id=411444 Downgrading to pinentry 0.9.0 solves the crash. Reproducible: Always Steps to Reproduce: 1. Run pinentry on a terminal 2. After "OK Pleased to meet you" insert "getpin" and press return 3. In the open dialog simply press return again. 4. The program should crash and display a backtrace Portage 2.2.20.1 (python 2.7.9-final-0, default/linux/amd64/13.0, gcc-4.8.5, glibc-2.20-r2, 3.18.16-gentoo x86_64) ================================================================= System uname: Linux-3.18.16-gentoo-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T9600_@_2.80GHz-with-gentoo-2.2 KiB Mem: 4051172 total, 245424 free KiB Swap: 4194300 total, 4193236 free Timestamp of repository gentoo: Wed, 09 Sep 2015 17:30:01 +0000 sh bash 4.3_p39 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.3_p39::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.9-r1::gentoo, 3.4.1::gentoo dev-util/cmake: 3.2.2::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.17::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.24-r3::gentoo sys-devel/gcc: 4.8.5::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.20-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 steam-overlay location: /var/lib/layman/steam-overlay masters: gentoo priority: 0 local location: /usr/local/portage masters: gentoo priority: 1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA PUEL dlj-1.1 RTCW-ETEULA Oracle-BCLA-JavaSE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -msse4.1 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=core2 -msse4.1 -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--tree --load-average 3 --jobs 2" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.rnl.ist.utl.pt/pub/gentoo/gentoo-distfiles/ http://cesium.di.uminho.pt/pub/gentoo/ http://ftp.dei.uc.pt/pub/linux/gentoo/" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp" USE="X alsa amd64 bzip2 cjk cli cracklib crypt cups cxx dbus dri firefox fortran gdbm gif gnutls iconv ipv6 jpeg lcms libnotify mmx mmxext modules multilib ncurses nls nptl opengl openmp pcre png python readline sdl seccomp session smp sse sse2 sse3 ssl ssse3 tcpd threads tiff truetype unicode zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="actions alias auth_basic auth_digest authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache 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_ftp proxy_http rewrite setenvif speling status unique_id userdir usertrack vhost_alias wsgi" APACHE2_MPMS="worker" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3 sse4 sse4_1" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="joystick keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ja" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="vesa nv nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 3.4" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Please follow bug#552614 comment#13 regarding nostrip.
I did, but as said in the description, it didn't change the backtrace produced. Note that this is not a backtrace produced by gdb. It simply shows up on my terminal when the program crashes. I can't even redirect it to a file with &>file. Had to copy-paste from terminal.
ok, so no gdb no symbols... difficult... maybe best to refine issue first... try 0.9.1...0.9.4 from[1], see where it breaks so we can diff the two versions. [1] http://mirrors.dotsrc.org/gcrypt/pinentry/
Created attachment 411564 [details] configure output
Ok so I tried manual compiling them and 0.9.4 doesn't crash whereas 0.9.5 does. I also noticed this in the configure step: ... checking for GPG Error - version >= 1.16... yes (1.19) configure: WARNING: *** *** The config script /usr/bin/gpg-error-config was *** built for x86_64-pc-linux-gnu and thus may not match the *** used host x86_64-unknown-linux-gnu. *** You may want to use the configure option --with-gpg-error-prefix *** to specify a matching config script or use $SYSROOT. *** checking for libassuan-config... /usr/bin/libassuan-config checking for LIBASSUAN - version >= 2.1.0... yes (2.2.1) checking LIBASSUAN API version... okay configure: WARNING: *** *** The config script /usr/bin/libassuan-config was *** built for x86_64-pc-linux-gnu and thus may not match the *** used host x86_64-unknown-linux-gnu. *** You may want to use the configure option --with-libassuan-prefix *** to specify a matching config script. *** checking for byte typedef... no ... Tried to recompile these two libs but the configure error persisted as did the crash.
Created attachment 411566 [details] make output
Additionally, this seems to only affect the gtk backend. The curses interface works fine. x11-libs/gtk+ 2.24.28-r1 and 3.16.6 installed
Also, about: checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu I'm not really sure where that is coming from given: # gcc-config -l [1] x86_64-pc-linux-gnu-4.8.5 *
(In reply to Renato Alves from comment #7) > Additionally, this seems to only affect the gtk backend. The curses > interface works fine. > > x11-libs/gtk+ 2.24.28-r1 and 3.16.6 installed I'm having problems reproducing this, but it seems related to https://bugs.gnupg.org/gnupg/issue2076 so it is an upstream issue. That one seems specific to passphrases of a certain length, can you verify if this is the case for you as well (just generate a test key or try symmetric encryption)
I just pushed pinentry 0.9.6 to ~arch. Can you please verify that the issue persists in this version?
Upstream response: 23:03 < K_F> neal: fwiw, c.f https://bugs.gnupg.org/gnupg/issue2076 we have a fresh report at https://bugs.gentoo.org/show_bug.cgi?id=560158 if you need more user feedback for debugging 01:32 < neal> K_F: Thanks for the heads up! 01:33 < neal> neal: It might be worthwhile trying to run pinentry under valgrind 01:33 < neal> K_F: Since the reporter seems willing to help a git bisect would be very useful!
Indeed it seems related. I just tried it and I managed to crash it in a different way. Steps to reproduce: 1. run pinentry (default gtk backend) 2. ask for pin (getpin) 3. in the GUI input 15 characters (I tried 15 zeros (0)) 4. input a 16th character. Pinentry crashes right away. The dump looks quite similar to the previous except the error was somewhere else: % pinentry OK Pleased to meet you getpin *** Error in `pinentry': realloc(): invalid pointer: 0x00007fe6225a5bc8 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x72c8f)[0x7fe62092cc8f] /lib64/libc.so.6(+0x780de)[0x7fe6209320de] /lib64/libc.so.6(realloc+0x26a)[0x7fe6209362fa] /usr/lib64/libglib-2.0.so.0(g_realloc+0xf)[0x7fe620f0721f] pinentry[0x40d317] /usr/lib64/libgobject-2.0.so.0(g_closure_invoke+0x138)[0x7fe621200338] ... Note that before the failure was on "free()" while now it's on "realloc()". ----- As for 0.9.6. I can't reproduce it there. It seems to work fine. I did notice a slight difference in the GUI elements used in 0.9.5 vs 0.9.6. Compare the following attachments.
Created attachment 411946 [details] pinentry-gtk 0.9.5
Created attachment 411948 [details] pinentry-gtk 0.9.6
Given it seems fixed, is a git bisect still relevant?
(In reply to Renato Alves from comment #15) > Given it seems fixed, is a git bisect still relevant? No, closing the bug as fixed in that case. Thanks for testing
Glad to help. Cheers, Renato
Hi Renato, Upstream here. Although the bug appears to be fixed in 0.9.6 (this might be because we changed from using our custom widget, which uses locked memory for storing the passphrase, to using standard widgets), I'm a bit worried that this bug might still be hiding somewhere. If you have time, I would greatly appreciate it if you could run a git bisect so that we can figure out where the bug was introduced! Thanks a lot! Neal
Hi Neal, Could you provide the git repo URL. I can't seem to find it on the website, only tarball releases. I've tested tarballs before. 0.9.4 is good, 0.9.5 is bad, 0.9.6 is good again.
Nevermind, got it.
(In reply to Renato Alves from comment #20) > Nevermind, got it. Just in case anyone else wonder, for reference it is http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=summary
Neal, so: git clone git://git.gnupg.org/pinentry.git ... 302903f76b8d62b1e07219a203f7219cb3aff7d8 is the first bad commit If this is relevant, this is what I have on the system: =dev-libs/libassuan-2.2.1 =dev-libs/libgpg-error-1.19 ----- On a side note, you may want to fix your configure.ac. I had to apply: diff --git a/configure.ac b/configure.ac index b71cb17..b458189 100644 --- a/configure.ac +++ b/configure.ac @@ -33,7 +33,7 @@ m4_define(mym4_version, [0.9.5]) # flag indicating a development version (mym4_isgit). Note that the # m4 processing is done by autoconf and not during the configure run. m4_define([mym4_revision], m4_esyscmd([git branch -v 2>/dev/null \ - | awk '/^\* / {printf "%s",$3}'])) + | awk '/^\* / {printf "%s",$8}'])) m4_define([mym4_revision_dec], m4_esyscmd_s([echo $((0x$(echo ]mym4_revision[|head -c 4)))])) m4_define([mym4_betastring], to temporarily workaround the following autogen.sh (strange) error during bisect: sh: 0xbran: value too great for base (error token is "0xbran") Basically, the awk expression is incorrect and will fail if the branchname has spaces. Which is true for bisect and detached HEADs. During bisect, git bisect -v returns: * (no branch, bisect started on 404943e) 302903f Remove internal mini-libassuan implementation and link to libassuan. master c64d1f4 Post release updates Anyway, have fun :)
Hi Renato, I appreciate your quick response! Neal
Hi Renato, I still can't reproduce the bug with the specified commit. Since you've build pinentry, you probably have debug symbols available. Could you try running pinentry under gdb and getting a backtrace and/or under valgrind? Thanks! Neal
Hi Neal, So with gdb I get nothing as stated before. I can't crash it in the same way, so no traceback. With valgrind I got something right after typing in getpin<Return> . The error message is "Conditional jump or move depends on uninitialised value(s)" error. More on the attached logfile.
Created attachment 412030 [details] Valgrind logfile
Thanks! Can you rerun valgrind with --track-origins=yes, please? Also, when running under valgrind, you get the message after typing getpin<enter>, but before the dialog is shown? Is that correct? Does pinentry still crash when running under valgrind? Thanks!
Created attachment 412034 [details] Valgrind logfile with track-origins=yes It looks kind of like half way through the widget creation. I see a window already but the widgets are not visible yet. No it doesn't crash in valgrind either. Same as gdb. And given the message in the logs, this is probably relevant: % equery belongs /usr/lib64/libgtk-x11-2.0.so.0.2400.28 * Searching for /usr/lib64/libgtk-x11-2.0.so.0.2400.28 ... x11-libs/gtk+-2.24.28-r1 (/usr/lib64/libgtk-x11-2.0.so.0.2400.28) % equery belongs /usr/lib64/libgobject-2.0.so.0.4400.1 * Searching for /usr/lib64/libgobject-2.0.so.0.4400.1 ... dev-libs/glib-2.44.1 (/usr/lib64/libgobject-2.0.so.0.4400.1)
