Strange crash in QApplication constructor

Pl45m4

I've tested it as well and experienced the same as @Christian-Ehrlicher ... worked for me on Windows with Qt6.8.
(I didn't used pre-compiled headers, though)

IgKh

I second the two replies above. The stack trace makes no sense, although the code as written should be perfectly valid. I suspect that maybe in your precompiled headers, the definition of qApp macro is the one from qcoreapplication.h rather than the one from qapplication.h. Try changing from using precompiled header to normal include of <QApplication>?

Jakob Kenda

Thank you for your replies. I'll just answer to all of you in one.

@Pl45m4 The change makes no difference, the program still crashes in the same place. There are no issues on Windows for me either, only on Linux.

@IgKh I know the stack trace makes no sense, that's why I'm writing on the forum. If I could've figured this out myself I wouldn't be here.
I tried compiling without a PCH but the behaviour still stays the same. This is the modified code:

#include "QtWidgets/qapplication.h"
#include <iostream>

static void use_qapp(QApplication* qApplication)
{
  std::cout << qApp << '\n';
}

There's no change in the behaviour of the program.

@Christian-Ehrlicher I'm building the application with CMake. RPATH is set to $ORIGIN and all the necessary Qt .so files copied to the same directory as the executable. Although debugging I set the LD_LIBRARY_PATH to the directory where Qt libraries were downloaded by the Qt Maintainance Tool, the behavoiur of the program was identical in both cases.
I also tried debugging ld with LD_DEBUG=libs in case there was a problem with loading the wrong SO or loading the same SO twice but the outputs of both programs were identical up to the point where one crashed.

I suspect the problems likely have something to do with putting the shared objects along with the executable, which is an unconventional approach on Linux, but I just can't figure out why that would be a problem.

JonB

@Jakob-Kenda
I don't know where it would get you, but have you tried comparing the value of the qApp (QApplication::instance()) where you use it against the address of the QApplication qApplication in your main()? I presume they are supposed to be equal [they are for me], are they?

Also, although it should not, does it differ if you use qApp back in main() or in some function which is not static?

Finally per the stack trace it looks to me like it is happening inside the QApplication qApplication constructor rather than later on, e.g. during use_qapp(). Put some debug output statements in to make sure you really do come out of the constructor and proceed to later statements?

Christian Ehrlicher

Please start with QT_DEBUG_PLUGINS - it looks like the xcb plugin gets not loaded, only the offscreen one.

IgKh

@Jakob-Kenda said in Strange crash in QApplication constructor:

I suspect the problems likely have something to do with putting the shared objects along with the executable, which is an unconventional approach on Linux, but I just can't figure out why that would be a problem.

That is a good hint, you should have mentioned that the application is deployed, and not run from the build tree as is. This approach is not as unusual as you say, this is the principal that AppImage packages operate on. You can use Qt like this, but it is more involved than just copying shared libraries and adjusting RPATH. The issue is plugins, which require a particular directory structure, and in many cases a qt.conf file to ensure the right set of plugins is used. Mismatch is the source of many a bizarre issue, although it is unclear how exactly it happens in your case. The information from running the application with LD_DEBUG and QT_DEBUG_PLUGINS may help.

You may also be interested in something like https://github.com/linuxdeploy/linuxdeploy-plugin-qt/ to automate correct deployment of Qt.

Jakob Kenda

@Christian-Ehrlicher said in Strange crash in QApplication constructor:

Please start with QT_DEBUG_PLUGINS - it looks like the xcb plugin gets not loaded, only the offscreen one.

The xcb plugin was loaded - Here is the QT_DEBUG_PLUGINS output.

Even if the plugin wasn't found, this wouldn't cause a crash where it did.

Jakob Kenda

@IgKh said in Strange crash in QApplication constructor:

The information from running the application with LD_DEBUG and QT_DEBUG_PLUGINS may help.

Here is the output of LD_DEBUG=libs, you may find something I missed despite looking at it for 2 days :)

JonB

@Jakob-Kenda said in Strange crash in QApplication constructor:

I have 2 applications, one of them is crashing and the other one isn't.

Have you at least output const char *qVersion() (not QT_VERSION_STR) in both just to make sure?

IgKh

@Jakob-Kenda Correct me if I'm wrong, but that looks like it was taken with the LD_LIBRARY_PATH set to the Qt installation?

Jakob Kenda

@IgKh Yes, that was for debugging purposes. Doesn't matter, the outcome is the same.

SGaist

Hi,

If I were you, I would check the code generated by the compiler.
I suspect some optimization might get applied or static initialization order is at play. Also note that qApp is a macro.
One thing you can do is try is using QApplication::instance() in place of qApp.

Jakob Kenda

@SGaist I know it's a macro, I've already tried expanding it myself; the result was exactly the same.

I'll try to analyze the generated code, thanks.