qt 5.15.9 - libqxcb SIGSEGV, Segmentation fault.

CamiloD

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.

SGaist

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.

Axel Spoerl

@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 libqxcbstarts the heavy lifting only after things happen on the screen. So you have to inspect the constructor for a faulty statement.

CamiloD

@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.

CamiloD

@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 to libxkbcommon , which I assume is the one throwing the error, but I no further information is given. Any thoughts ?

I appreciate the help.

SGaist

@CamiloD I can assure you, 9 years ago, subclassing QApplication wasn't a thing.

Back to our issue, does starting a standard dummy application work at all ?
Is it the Qt version coming with your distribution ?

CamiloD

This post is deleted!

CamiloD

@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.

SGaist

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.