keepass2-alpha6 after entering the password for keyfile crashes with Bus error. Also register PR in upstream: https://www.keepassx.org/dev/issues/247 Nevertheless, it is possible FreeBSD-specific problem. What do you think about this? System: 11.0-CURRENT/amd64 + 10.1-RELEASE/amd64 -- Program received signal SIGBUS, Bus error. [Switching to Thread 806c06400 (LWP 100222/keepassx)] 0x0000000801dd80d4 in _gcry_salsa20_amd64_encrypt_blocks () from /usr/local/lib/libgcrypt.so.20 (gdb) bt #0 0x0000000801dd80d4 in _gcry_salsa20_amd64_encrypt_blocks () from /usr/local/lib/libgcrypt.so.20 #1 0x0000000000000001 in ?? () #2 0x00000000002d91a0 in ?? () #3 0x0000000806c0658c in ?? () #4 0x0000000000000023 in ?? () #5 0x00007fffffffc500 in ?? () #6 0x00000008038a7825 in pthread_getspecific () from /lib/libthr.so.3 #7 0x0000000801dd6fc8 in _gcry_camellia_aesni_avx2_cfb_dec () from /usr/local/lib/libgcrypt.so.20 #8 0x0000000801dd66ab in _gcry_camellia_aesni_avx2_cfb_dec () from /usr/local/lib/libgcrypt.so.20 #9 0x0000000801d6d61e in gcry_is_secure () from /usr/local/lib/libgcrypt.so.20 #10 0x0000000801d60491 in gcry_cipher_setkey () from /usr/local/lib/libgcrypt.so.20 #11 0x000000000046781a in AutoTypeExecutor::execClearField () #12 0x00000000004844dc in AutoTypeExecutor::execClearField () #13 0x0000000000485024 in AutoTypeExecutor::execClearField () #14 0x0000000000476316 in AutoTypeExecutor::execClearField () #15 0x0000000800ba3c0d in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #16 0x00000008015ea7e3 in QDialogButtonBox::standardButton () from /usr/local/lib/qt4/libQtGui.so.4 #17 0x00000008015eaf68 in QDialogButtonBox::event () from /usr/local/lib/qt4/libQtGui.so.4 #18 0x0000000800ba3c0d in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #19 0x000000080186c8c1 in QAbstractButton::clicked () from /usr/local/lib/qt4/libQtGui.so.4 #20 0x00000008015bcb44 in QAbstractButton::isCheckable () from /usr/local/lib/qt4/libQtGui.so.4 #21 0x00000008015bc6a5 in QAbstractButton::click () from /usr/local/lib/qt4/libQtGui.so.4 #22 0x0000000000450549 in AutoTypeExecutor::execClearField () #23 0x0000000000450405 in AutoTypeExecutor::execClearField () #24 0x000000080125e533 in QWidget::event () from /usr/local/lib/qt4/libQtGui.so.4 #25 0x00000008012114bd in QApplicationPrivate::notify_helper () from /usr/local/lib/qt4/libQtGui.so.4 #26 0x0000000801214212 in QApplication::notify () from /usr/local/lib/qt4/libQtGui.so.4 #27 0x0000000800b8c3a6 in QCoreApplication::notifyInternal () from /usr/local/lib/qt4/libQtCore.so.4 #28 0x0000000801214b6d in QApplicationPrivate::currentPlatform () from /usr/local/lib/qt4/libQtGui.so.4 #29 0x00000008012ae72d in QX11Info::isCompositingManagerRunning () from /usr/local/lib/qt4/libQtGui.so.4 #30 0x00000008012ae405 in QX11Info::isCompositingManagerRunning () from /usr/local/lib/qt4/libQtGui.so.4 #31 0x0000000801285549 in QApplication::x11ProcessEvent () from /usr/local/lib/qt4/libQtGui.so.4 #32 0x00000008012b07c1 in QX11Info::isCompositingManagerRunning () from /usr/local/lib/qt4/libQtGui.so.4 #33 0x00000008031c9fb8 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #34 0x00000008031ca34e in g_main_context_pending () from /usr/local/lib/libglib-2.0.so.0 #35 0x00000008031ca3d4 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #36 0x0000000800bb8ef1 in QEventDispatcherGlib::processEvents () from /usr/local/lib/qt4/libQtCore.so.4 #37 0x00000008012b049d in QX11Info::isCompositingManagerRunning () from /usr/local/lib/qt4/libQtGui.so.4 #38 0x0000000800b899cf in QEventLoop::exec () from /usr/local/lib/qt4/libQtCore.so.4 #39 0x0000000800b8c95d in QCoreApplication::exec () from /usr/local/lib/qt4/libQtCore.so.4 #40 0x000000000042203f in _start () #41 0x000000000042153f in _start () #42 0x00000008006d5000 in ?? () #43 0x0000000000000000 in ?? () --
Maintainer CC'd
add CC for security/libgcrypt maintainer
It crashed at cipher/salsa20.c,salsa20-amd64.S in libgcrypt, in my test undefine USE_AMD64 in cipher/salsa20.c will fix this. I guess libgcrypt's asm code is not fully compatible with clang.
(In reply to Eric Camachat from comment #3) perhaps undefine that you have done is canceled this changes: https://bugs.g10code.com/gnupg/issue1668 So, looks like is FreeBSD-specific problem + libcrypt
Try to rebuild libgcrypt without O2 option.
(In reply to Ivan from comment #5) rebuild with CFLAGS=-O0 COPTFLAGS=-O0 not solved issue.
(In reply to olevole from comment #6) Works for me. 10.1-RELEASE amd64
I've been hit with the same bug with 10.1-RELEASE-p3. Problem lies in the compiling of cipher/salsa20.c in libgcrypt and/or keepassx's interaction with the libgcrypt salsa20 routines. If you compile libgcrypt with "USE_GCC= any" set, keepassx works. If you use the default CLANG's cc but with "CFLAGS= -O1", keepassx also works. I've narrowed it down to compiling just the cipher/salsa20.c module in libgcrypt with "-O1" and the rest with "-O2" will allow keepassx to work. I've just sent an email to the new maintainer of libgcrypt with that information (and ugly patch to port's Makefile) as well to consider. Now the finger pointing.. Is it CLANG's optimizations or libgcrypt's salsa20 code or keepassx calling libgcrypt with bad data? ivan. (different ivan).
(In reply to Ivan Brawley from comment #8) "CFLAGS= -O1" works for me too (unlike -O0)
(In reply to Ivan Brawley from comment #8) As Ivan told previously, I'm aware of this problem. So I'll submit a patch over the comming days. Best regards.
Ivan's workaround didn't work for my 11-CURRENT.
Created attachment 151916 [details] disable asm in libgcrypt on amd64 workaround for keepassx2 crash.
Created attachment 151984 [details] libgcrypt.diff The patch submitted by Ivan fixes the ASM build problem on 11-CURRENT/amd64. At the moment, I only tested it on 11-CURRENT/i386. Please test it, and send your feedback.
(In reply to Eric Camachat from comment #11) Eric, please show us your build log.
Created attachment 151992 [details] security/libgcrypt build logs Here are my build logs with Ivan's patch on 11-CURRENT/amd64. USE_GCC=any worked, clang with -O1 compiled but crashed in runtime. In addition, build with clang, compiled but crashed in runtime (is is expected).
(In reply to Eric Camachat from comment #15) I think I've reproduced what you are seeing. And after syncing up my 11-CURRENT VM to the most recent. You are setting CFLAGS somewhere else? (environment variable or /etc/make.conf?) I can see in your cc_is_clang log there are some extra options to cc. And in your cc_is_clang-O1 log, I can't see it actually using that. If I set $CFLAGS env variable with "-pipe -march=corei7 -g" (-m and -g are the extra options), configure doesn't add any -O options and I get the crash. But if I also add -O2 to the list, all is good. In fact, setting $CFLAGS to just "-pipe" so that the cc commands are the same as the defaults with the -O option removed, it still crashes. And the same thing for -O0. Which is odd as I tested that before (perhaps that testing produced incorrect results). Doing some more debugging, there is a bug in the libgcrypt's cipher/Makefile when turning down the optimisations for cipher/tiger.o (and with my patch, for cipher/salsa20.c). It echos a libtool commandline through sed to change the -Oblah to -O1, but the first s// sed command will only change the first instance of -Oblah found, not all of them. So you could end up with multiple different -Oblah options to cc, which will further complicate debugging, etc. Eric, try having a look around your Makefile, env variables and /etc/make.conf, etc to see if you are also trying to set CFLAGS and remove it so that it will compile libgcrypt with a clean environment. You should see in the build log the rest of the modules compiling with -O2 for instance. ivan.
It works with Ivan's patch and this build command. # cd /usr/ports/security/libgcrypt && make clean build deinstall reinstall clean CFLAGS="-pipe -march=corei7 -O2" No need to rebuild security/keepassx2.
This will force use -O2 to compile libgcrypt (use with Ivan's patch). Index: security/libgcrypt/Makefile =================================================================== --- security/libgcrypt/Makefile (revision 377699) +++ security/libgcrypt/Makefile (working copy) @@ -63,3 +63,4 @@ cd ${WRKSRC} && ${MAKE_CMD} check .include <bsd.port.mk> +CFLAGS:= ${CFLAGS:N-O*} -O2
(In reply to Eric Camachat from comment #17) Fine, but note that generally is better to leave the compiler do it for you, instead use such kind of "-m" options. If nobody complain then I'll submit the PORTREVISION.
Furthermore we need to test final changes via poudriere on FreeBSD/amd64. Currently I don't have an amd64 machine. Can anyone here do it?
Created attachment 152100 [details] libgcrypt.diff Following patch fixes crash at cipher/salsa20.c module on amd64. Also I added ${STRIP_CMD} variable to strip properly libgcrypt.so.20.0.2
Created attachment 152102 [details] libgcrypt.diff
Created attachment 152103 [details] libgcrypt.diff
Created attachment 152181 [details] libgcrypt.diff Poudriere complained at pre-processing stage. After I changed the order of both variables, it doesn't complain.
Build logs on i386: https://fbsd.es/~cpm/freebsd/poudriere/freebsd:8:x86:32/libgcrypt-1.6.2_1.log https://fbsd.es/~cpm/freebsd/poudriere/freebsd:9:x86:32/libgcrypt-1.6.2_1.log https://fbsd.es/~cpm/freebsd/poudriere/freebsd:10:x86:32/libgcrypt-1.6.2_1.log
Carlos, could you include the logs referenced in comment 25 as attachments to this issue please
Created attachment 152257 [details] libgcrypt-1.6.2_1.zip Done!
The patch is for liggcrypt actually, I am not maintainer of security/libgcrypt. We should inform cpm@fbsd.es that record in security/ligbcrypt/Makefile.
The change is committed for libgcrypt. So this can be closed.