segfault in qt?

[recohen]

I installed xtalopt several times several different ways, but it always segfaults as follows. I am running centos
(rec4) rcohen@tomcat:~/XtalOpt/buildgnu$ cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)

gdb bin/xtalopt
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 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 "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/rcohen/XtalOpt/buildgnu/bin/xtalopt...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/rcohen/XtalOpt/buildgnu/bin/xtalopt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00002aaab1c2bb8c in _GLOBAL__sub_I_qprinterinfo.cpp () from /lib64/libQtGui.so.4
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.176-5.el7.x86_64 elfutils-libs-0.176-5.el7.x86_64 expat-2.1.0-12.el7.x86_64 fontconfig-2.13.0-4.3.el7.x86_64 freetype-2.8-14.el7_9.1.x86_64 glib2-2.56.1-8.el7.x86_64 glibc-2.17-317.el7.x86_64 graphite2-1.3.10-1.el7_3.x86_64 harfbuzz-1.7.5-2.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-50.el7.x86_64 libICE-1.0.9-9.el7.x86_64 libSM-1.2.2-2.el7.x86_64 libX11-1.6.7-3.el7_9.x86_64 libXau-1.0.8-2.1.el7.x86_64 libXcursor-1.1.15-1.el7.x86_64 libXext-1.3.3-3.el7.x86_64 libXfixes-5.0.3-1.el7.x86_64 libXi-1.7.9-1.el7.x86_64 libXinerama-1.1.3-2.1.el7.x86_64 libXrandr-1.5.1-2.el7.x86_64 libXrender-0.9.10-1.el7.x86_64 libattr-2.4.46-13.el7.x86_64 libcap-2.22-11.el7.x86_64 libcom_err-1.42.9-19.el7.x86_64 libffi-3.0.13-19.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 libgcrypt-1.5.3-14.el7.x86_64 libglvnd-1.0.1-0.8.git5baa1e5.el7.x86_64 libglvnd-glx-1.0.1-0.8.git5baa1e5.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libicu-50.2-4.el7_7.x86_64 libpng-1.5.13-8.el7.x86_64 libselinux-2.5-15.el7.x86_64 libssh-0.7.1-7.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 libuuid-2.23.2-65.el7.x86_64 libxcb-1.13-1.el7.x86_64 lz4-1.8.3-1.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 pcre-8.32-17.el7.x86_64 pcre2-utf16-10.23-2.el7.x86_64 qt-4.8.7-9.el7_9.x86_64 qt-x11-4.8.7-9.el7_9.x86_64 qt5-qtbase-5.9.7-5.el7_9.x86_64 qt5-qtbase-gui-5.9.7-5.el7_9.x86_64 qwt-6.1.1-1.el7.x86_64 systemd-libs-219-78.el7_9.2.x86_64 xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) back
#0 0x00002aaab1c2bb8c in _GLOBAL__sub_I_qprinterinfo.cpp () at /lib64/libQtGui.so.4
#1 0x00002aaaaaaba9c3 in _dl_init_internal () at /lib64/ld-linux-x86-64.so.2
#2 0x00002aaaaaaac17a in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#3 0x0000000000000001 in ()
#4 0x00007fffffffde63 in ()
#5 0x0000000000000000 in ()
(gdb)

[recohen]

I finally got xtalopt to install. The problem was qwt. But fixing it was a mess. I had to do the folowing:

make new conda python3 environment
sudo yum remove qwt
sudo yum install qwt qwt-devel
rpm -ql qwt
rpm -ql qwt-devel
cd buildgnu
cmake .. -DCMAKE_INSTALL_PREFIX=/home/rcohen -DQWT_LIBRARY=/usr/lib64/libqwt.so.6 -DQWT_INCLUDE_DIR=/usr/include/qwt/
make -j 8
sudo vi /usr/include/qwt/qwt_transform.h #it seems there is a bug here. see below
make
make install

Here is the bug info:
[ 85%] Building CXX object src/xtalopt/CMakeFiles/xtalopt_static.dir/ui/dialog.cpp.o
In file included from /usr/include/qwt/qwt_scale_map.h:14:0,
from /usr/include/qwt/qwt_plot.h:16,
from /home/rcohen/XtalOpt/src/xtalopt/ui/xtalopt_plot.h:22,
from /home/rcohen/XtalOpt/buildgnu/src/xtalopt/xtalopt_static_autogen/include/ui_tab_plot.h:23,
from /home/rcohen/XtalOpt/src/xtalopt/ui/tab_plot.h:22,
from /home/rcohen/XtalOpt/src/xtalopt/ui/dialog.cpp:27:
/usr/include/qwt/qwt_transform.h:110:5: error: \u2018QT_STATIC_CONST\u2019 does not name a type; did you mean \u2018Q_STATIC_TYPE\u2019?
QT_STATIC_CONST double LogMin;
^~~~~~~~~~~~~~~
Q_STATIC_TYPE
/usr/include/qwt/qwt_transform.h:111:5: error: \u2018QT_STATIC_CONST\u2019 does not name a type; did you mean \u2018Q_STATIC_TYPE\u2019?
QT_STATIC_CONST double LogMax;
^~~~~~~~~~~~~~~
Q_STATIC_TYPE

I fixed by just deleting QT_STATIC_CONST so that Logmin and LogMax are double . If this is not the correct fix please let me know. Why is there such a bug in a released code?

[July13210914]

I'll forward this to the people who worked on this. Thanks for reporting!

[psavery]

Hi @recohen. Sorry to hear you have had issues installing XtalOpt! Thank you for your backtrace and installation details.

We have not had many users on CentOS, so that is likely why we have not ran into these issues previously.

It looks to me that qwt installed via yum install qwt uses Qt4, whereas XtalOpt uses Qt5. Qt4 and Qt5 are not compatible, and this is probably causing the issue. I have a few ideas you could try (and maybe @lilithean can help too):

1. Search to see if there is a qwt somewhere that was built with Qt5, and use that.
2. If that doesn't work, you may need to build qwt locally using Qt5.
3. You could also potentially try to use the released binaries here. This comes with most of the dependencies, including Qt5 and Qwt, pre-packaged. You may have to install one or two other dependencies such as harfbuzz.

[recohen]

Thank you so much. Yes I found that I needed to use qwt installed with conda. qt is such a mess! So is python these days. Incompatible versions are a mess. Thanks again! It is working fine for me now. One another note ( I should submit a suggestion) I think there should be an option to not have to log in from xtalopt. I run xtalopt on my headnode and use slurm to submit to compute nodes. I suspect many people run this way. So I do not need to have xtalopt log into the headnode. Allowing a program to log in is a security issue I think, and not always so straightforward if one is using 2 factor authentication for example. Sincerely, Ron

…

On Mar 11, 2021, at 9:35 AM, Patrick Avery ***@***.***> wrote: Hi @recohen <https://github.com/recohen>. Sorry to hear you have had issues installing XtalOpt! Thank you for your backtrace and installation details. We have not had many users on CentOS, so that is likely why we have not ran into these issues previously. It looks to me that qwt installed via yum install qwt uses Qt4, whereas XtalOpt uses Qt5. Qt4 and Qt5 are not compatible, and this is probably causing the issue. I have a few ideas you could try (and maybe @lilithean <https://github.com/lilithean> can help too): Search to see if there is a qwt somewhere that was built with Qt5, and use that. If that doesn't work, you may need to build qwt locally using Qt5 <https://qwt.sourceforge.io/qwtinstall.html>. You could also potentially try to use the released binaries here <https://github.com/xtalopt/XtalOpt/releases/download/r12.3/linux-xtalopt.tgz>. This comes with most of the dependencies, including Qt5 and Qwt, pre-packaged. You may have to install one or two other dependencies such as harfbuzz. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABA2R5KQYKWRDSTBBVZU7YTTDDBKHANCNFSM4Y2GBO3A>.

--- Ronald Cohen Extreme Materials Initiative Carnegie Institution for Science 5251 Broad Branch Rd., N.W. Washington, D.C. 20015 ***@***.*** ***@***.***> office: 202-478-8937 skype: ronaldcohen twitter: @recohen3