qt 5.15.9 - libqxcb SIGSEGV, Segmentation fault.
-
Hello all,
I am trying to run a software developed in qt. It uses the plugin libqxcb.
The code breaks after executing the constructor of the class inheriting from QApplication:class MApplication : public QApplication { public: MApplication(int& argc, char** argv) : QApplication(argc, argv) { /** a lot of code here that is never reached **/ } }; int main(int argc, char** argv) { QC oreApplication::setAttribute(Qt::AA_ShareOpenGLContexts); MApplication app(argc, argv); // it breaks here }
This is the output threw by gdb, but it really doesnt say anything useful. Any thoughts??
Thread 1 "XMALab" received signal SIGSEGV, Segmentation fault. 0x00007fffc627f815 in atom_intern () from /oscar/rt/9.2/software/0.20-generic/0.20.1/opt/spack/linux-rhel9-x86_64_v3/gcc-11.3.1/libxkbcommon-1.4.0-ptmcwmexqbwi3seltwnaoqgykxtkl53e/lib/libxkbcommon-x11.so.0 Missing separate debuginfos, use: dnf debuginfo-install at-spi2-atk-2.38.0-4.el9.x86_64 at-spi2-core-2.40.3-1.el9.x86_64 atk-2.36.0-5.el9.x86_64 bzip2-libs-1.0.8-8.el9.x86_64 cairo-1.17.4-7.el9.x86_64 cairo-gobject-1.17.4-7.el9.x86_64 dbus-libs-1.12.20-7.el9_1.x86_64 fontconfig-2.14.0-2.el9_1.x86_64 freetype-2.10.4-9.el9.x86_64 fribidi-1.0.10-6.el9.2.x86_64 gdk-pixbuf2-2.42.6-3.el9.x86_64 glib2-2.68.4-6.el9.x86_64 glibc-2.34-60.el9.x86_64 graphite2-1.3.14-9.el9.x86_64 gtk3-3.24.31-2.el9.x86_64 harfbuzz-2.7.4-8.el9.x86_64 jbigkit-libs-2.1-23.el9.x86_64 json-glib-1.6.6-1.el9.x86_64 libX11-1.7.0-7.el9.x86_64 libXau-1.0.9-8.el9.x86_64 libXcomposite-0.4.5-7.el9.x86_64 libXcursor-1.2.0-7.el9.x86_64 libXdamage-1.1.5-7.el9.x86_64 libXext-1.3.4-8.el9.x86_64 libXfixes-5.0.3-16.el9.x86_64 libXi-1.7.10-8.el9.x86_64 libXinerama-1.1.4-10.el9.x86_64 libXrender-0.9.10-16.el9.x86_64 libXv-1.0.11-16.el9.x86_64 libblkid-2.37.4-10.el9.x86_64 libbrotli-1.0.9-6.el9.x86_64 libcap-2.48-8.el9.x86_64 libdatrie-0.2.13-4.el9.x86_64 libepoxy-1.5.5-4.el9.x86_64 libffi-3.4.2-7.el9.x86_64 libgcc-11.3.1-4.3.el9.x86_64 libgcrypt-1.10.0-10.el9_1.x86_64 libgfortran-11.3.1-4.3.el9.x86_64 libglvnd-1.3.4-1.el9.x86_64 libglvnd-egl-1.3.4-1.el9.x86_64 libglvnd-glx-1.3.4-1.el9.x86_64 libquadmath-11.3.1-4.3.el9.x86_64 libselinux-3.5-1.el9.x86_64 libstdc++-11.3.1-4.3.el9.x86_64 libstemmer-0-18.585svn.el9.x86_64 libthai-0.1.28-8.el9.x86_64 libtiff-4.4.0-7.el9.x86_64 libtracker-sparql-3.1.2-3.el9_1.x86_64 libwayland-client-1.21.0-1.el9.x86_64 libwayland-cursor-1.21.0-1.el9.x86_64 libwayland-egl-1.21.0-1.el9.x86_64 libwebp-1.2.0-3.el9.x86_64 libxcb-1.13.1-9.el9.x86_64 libxkbcommon-1.0.3-4.el9.x86_64 lz4-libs-1.9.3-5.el9.x86_64 mesa-libGLU-9.0.1-6.el9.x86_64 pango-1.48.7-3.el9.x86_64 systemd-libs-252-13.el9_2.x86_64
My System:
- HPC / Linux RH9
- Using vnc to emulate the desktop.
- gcc 11.3
- qt 5.15.9
Thank you.
-
Hi and welcome to devnet,
What do you mean by "using vnc to emulate the desktop" ?
And out of curiosity, why are you subclassing QApplication ? There are only a few use cases for that.
-
@CamiloD
That (with an empty constructor) doesn't crash on my system.
Only two possibilities come to mind, when crashing in the XCB backend.libqxcb
crashes when loaded. That should affect all Qt apps in a KDE desktop, e.g. Dolphin or KDEpim.- Some of the "a lot of code that is never reached" actually causes the crash.
My money is on the second option, because there is a mismatch
The code breaks after executing the constructor of the class inheriting from QApplication.
The code comment insinuates, that the crash reproduces with an empty constructor. That is clearly not the case. The quoted statement admits that the crash happens after the constructor code has been executed. That makes much more sense, because
libqxcb
starts the heavy lifting only after things happen on the screen. So you have to inspect the constructor for a faulty statement. -
@SGaist
I am so sorry for the late reply, I didn't get any notification when you replied to my post.
I am trying to run it on a RHLE9 HPC system through X11 - Xserver to display gui applications. There is a way to visually access the system using virtual desktop (vnc).
To clarify, I did not originally develop this application; It was created in 2015 so I assume subclassing QApplication was the way things used to work back then. I am in the task on making it run in the system, not developing new features or making substantial modifications. As it is opensource I wanted to diagnose the error by attaching gdb and see the stack trace. -
@Axel-Spoerl
I am so sorry for the late reply, I didn't get any notification when you replied to my post.to verify your second point, I placed a
cout
inside the constructor:MApplication(int& argc, char** argv) : QApplication(argc, argv) { std::cout<<"Hello 1" << std::endl; /** a lot of code here that is never reached **/ }
But that Hello 1 message never gets printed, so my guess is that the crash happens inside the call to the constructor of the super class
QApplication
That is proven when I run the debugger attached to the process. The crash stack trace appears after I step over the call to the constructor
MApplication : QApplication(argc, argv)
.
Also, the log makes reference tolibxkbcommon
, which I assume is the one throwing the error, but I no further information is given. Any thoughts ?I appreciate the help.
-
@SGaist
I havent tested a dummy application, but In the HPC system we have Paraview-gui installed which was built using qt-5. However, that paraview was installed through a package manager, and it seems it downloaded its own dependencies.
The qt-gui lib I am linking the opensource application with didnt come with the linux distribution, it was installed using apt or spack. Should I try to installed from the source? What options should I need to run the configuration scripts with?
My issue is with the segmentation fault in the libxkbcommon dependency. I just cant figure out how to debugged it or diagnose this crash. -
What Linux distribution is used on your HPC nodes ?
Was Paraview installed directly on them ?Once that is defined, I would say you have mainly two options:
- Build your application with the Qt version used on the nodes
- Build your application using a compatible Qt version downloaded from the online installer
As a third option, you can build your own Qt version but I would try the other two first.
Note that there might be a bug in the libxkbcommon provided by spack.