Strange crash in QApplication constructor

Jakob Kenda

Hi,

I'm having a problem with the Qt application I'm developing.

I have 2 applications, one of them is crashing and the other one isn't. The crash occurs in QWindowSystemInterface::screenAdded because qGuiApp is null.

I've narrowed it down to QCoreApplication::self.storeRelaxed properly setting the global application in one application and having no effect in the other (QApplication::instance() and thus qApp stays null).

I tried to diagnose the problem with LD_DEBUG and it shows the libraries they are loading are exactly the same, in the same order and everything.

I don't know what else to do, can someone help me?

IgKh

@Jakob-Kenda welcome to the forum.

Unfortunately you did not give us any information to go on, not even the version of Qt you are using or on which operating system (and version).

Try to reduce your non working program as much as possible one thing at a time, until the issue disappeared (and then you know what caused it), or you are left with a minimal one file reproduction program you can post here.

If not that, at least provide your existing findings and why you think they point at an atomic store operation not working (which would be extremely unusual!)

Jakob Kenda

Sorry, I'm using Qt 6.9.3 on Ubuntu 22.04.

I was able to reproduce this minimally.
The only difference between crashing and not crashing is QCoreApplication::instance() being accessed. The curious thing is that the crash doesn't occur anywhere around the lines being changed but QCoreApplication::init.

This code produces a crash:

#include "pch.h"

static void use_qapp()
{
  QTimer timer(qApp);
}

int main(int argc, char** argv)
{
  // contruct, init FApplication and FGuiRunner
  QApplication qApplication(argc, argv);
  use_qapp();
  return 0;
}

while this one executes normally:

#include "pch.h"

static void use_qapp(QApplication* qApplication)
{
  QTimer timer(qApplication);
}

int main(int argc, char** argv)
{
  // contruct, init FApplication and FGuiRunner
  QApplication qApplication(argc, argv);
  use_qapp(&qApplication);
  return 0;
}

The stack trace (with Wayland platform):

#0  doActivate<false> (sender=0x0, signal_index=9, argv=argv@entry=0x7fffffffcfa0) at /home/qt/work/qt/qtbase/src/corelib/kernel/qobject.cpp:4050
#1  0x00007ffff79e0f28 in QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7ffff3eb77e0 <QGuiApplication::staticMetaObject>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fffffffcfa0)
    at /home/qt/work/qt/qtbase/src/corelib/kernel/qobject.cpp:4230
#2  0x00007ffff35de926 in QMetaObject::activate<void, QScreen*> (ret=0x0, local_signal_index=1, mo=0x7ffff3eb77e0 <QGuiApplication::staticMetaObject>, sender=<optimized out>) at /home/qt/work/qt/qtbase/src/corelib/kernel/qobjectdefs.h:306
#3  QGuiApplication::screenAdded (this=<optimized out>, _t1=<optimized out>) at /home/qt/work/qt/qtbase_build/src/gui/Gui_autogen/include/moc_qguiapplication.cpp:300
#4  0x00007ffff365cbdf in QWindowSystemInterface::handleScreenAdded (platformScreen=<optimized out>, isPrimary=isPrimary@entry=false) at /home/qt/work/qt/qtbase/src/gui/kernel/qwindowsysteminterface.cpp:730
#5  0x00007ffff2f6cb89 in QtWaylandClient::QWaylandDisplay::handleScreenInitialized (this=0x55555558a640, screen=<optimized out>, screen@entry=0x5555555978a0) at /home/qt/work/qt/qtwayland/src/client/qwaylanddisplay.cpp:607
#6  0x00007ffff2f962c3 in QtWaylandClient::QWaylandScreen::maybeInitialize (this=0x5555555978a0) at /home/qt/work/qt/qtwayland/src/client/qwaylandscreen.cpp:81
#7  QtWaylandClient::QWaylandScreen::maybeInitialize (this=0x5555555978a0) at /home/qt/work/qt/qtwayland/src/client/qwaylandscreen.cpp:72
#8  0x00007ffff2eb9b16 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#9  0x00007ffff2eb63ef in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#10 0x00007ffff2eb90be in ffi_call () from /lib/x86_64-linux-gnu/libffi.so.8
#11 0x00007ffff2ecebfe in ?? () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#12 0x00007ffff2ecf473 in ?? () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#13 0x00007ffff2ecf71c in wl_display_dispatch_queue_pending () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#14 0x00007ffff2ed250f in wl_display_roundtrip_queue () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#15 0x00007ffff2f6bb28 in QtWaylandClient::QWaylandDisplay::initialize (this=0x55555558a640) at /home/qt/work/qt/qtwayland/src/client/qwaylanddisplay.cpp:397
#16 QtWaylandClient::QWaylandDisplay::initialize (this=0x55555558a640) at /home/qt/work/qt/qtwayland/src/client/qwaylanddisplay.cpp:386
#17 0x00007ffff2f8ec8d in QtWaylandClient::QWaylandIntegration::init (this=this@entry=0x555555595260) at /home/qt/work/qt/qtwayland/src/client/qwaylandintegration.cpp:104
#18 0x00007ffff5e96323 in QtWaylandClient::QWaylandIntegrationPlugin::create (this=<optimized out>, system=..., paramList=...) at /home/qt/work/qt/qtwayland/src/plugins/platforms/qwayland-generic/main.cpp:25
#19 0x00007ffff35e43e1 in init_platform (pluginNamesWithArguments=..., platformPluginPath=..., platformThemeName=..., argc=@0x7fffffffdb3c: 1, argv=argv@entry=0x7fffffffdc98) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1309
#20 0x00007ffff35e7f0a in QGuiApplicationPrivate::createPlatformIntegration (this=0x555555581640) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1591
#21 0x00007ffff35e8988 in QGuiApplicationPrivate::createEventDispatcher (this=<optimized out>) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1610
#22 0x00007ffff798a966 in QCoreApplicationPrivate::init (this=this@entry=0x555555581640) at /home/qt/work/qt/qtbase/src/corelib/kernel/qcoreapplication.cpp:866
#23 0x00007ffff35ebc28 in QGuiApplicationPrivate::init (this=this@entry=0x555555581640) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1638
#24 0x00007ffff7198a6d in QApplicationPrivate::init (this=0x555555581640) at /home/qt/work/qt/qtbase/src/widgets/kernel/qapplication.cpp:476
#25 0x0000555555555279 in main (argc=1, argv=0x7fffffffdc98) at /mnt/c/BRANCHES/PoC/PoC/simple_example/src/main.cpp:11

with offscreen platform:

#0  doActivate<false> (sender=0x0, signal_index=9, argv=argv@entry=0x7fffffffd1b0) at /home/qt/work/qt/qtbase/src/corelib/kernel/qobject.cpp:4050
#1  0x00007ffff79e0f28 in QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7ffff3eb77e0 <QGuiApplication::staticMetaObject>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fffffffd1b0)
    at /home/qt/work/qt/qtbase/src/corelib/kernel/qobject.cpp:4230
#2  0x00007ffff35de926 in QMetaObject::activate<void, QScreen*> (ret=0x0, local_signal_index=1, mo=0x7ffff3eb77e0 <QGuiApplication::staticMetaObject>, sender=<optimized out>) at /home/qt/work/qt/qtbase/src/corelib/kernel/qobjectdefs.h:306
#3  QGuiApplication::screenAdded (this=<optimized out>, _t1=<optimized out>) at /home/qt/work/qt/qtbase_build/src/gui/Gui_autogen/include/moc_qguiapplication.cpp:300
#4  0x00007ffff365cbdf in QWindowSystemInterface::handleScreenAdded (platformScreen=platformScreen@entry=0x5555555939a0, isPrimary=isPrimary@entry=false) at /home/qt/work/qt/qtbase/src/gui/kernel/qwindowsysteminterface.cpp:730
#5  0x00007ffff2ff3204 in QOffscreenIntegration::setConfiguration (this=this@entry=0x555555595750, configuration=...) at /home/qt/work/qt/qtbase/src/plugins/platforms/offscreen/qoffscreenintegration.cpp:251
#6  0x00007ffff2ff43a5 in QOffscreenIntegration::QOffscreenIntegration (this=this@entry=0x555555595750, paramList=...) at /home/qt/work/qt/qtbase/src/plugins/platforms/offscreen/qoffscreenintegration.cpp:79
#7  0x00007ffff2ff7a0d in QOffscreenX11Integration::QOffscreenX11Integration (this=this@entry=0x555555595750, paramList=...) at /home/qt/work/qt/qtbase/src/plugins/platforms/offscreen/qoffscreenintegration_x11.cpp:44
#8  0x00007ffff2ff44ab in QOffscreenIntegration::createOffscreenIntegration (paramList=...) at /home/qt/work/qt/qtbase/src/plugins/platforms/offscreen/qoffscreenintegration.cpp:432
#9  0x00007ffff35e43e1 in init_platform (pluginNamesWithArguments=..., platformPluginPath=..., platformThemeName=..., argc=@0x7fffffffdb0c: 1, argv=argv@entry=0x7fffffffdc68) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1309
#10 0x00007ffff35e7f0a in QGuiApplicationPrivate::createPlatformIntegration (this=0x555555581640) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1591
#11 0x00007ffff35e8988 in QGuiApplicationPrivate::createEventDispatcher (this=<optimized out>) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1610
#12 0x00007ffff798a966 in QCoreApplicationPrivate::init (this=this@entry=0x555555581640) at /home/qt/work/qt/qtbase/src/corelib/kernel/qcoreapplication.cpp:866
#13 0x00007ffff35ebc28 in QGuiApplicationPrivate::init (this=this@entry=0x555555581640) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1638
#14 0x00007ffff7198a6d in QApplicationPrivate::init (this=0x555555581640) at /home/qt/work/qt/qtbase/src/widgets/kernel/qapplication.cpp:476
#15 0x0000555555555279 in main (argc=1, argv=0x7fffffffdc68) at /mnt/c/BRANCHES/PoC/PoC/simple_example/src/main.cpp:11

Edit:
I also checked which dynamic libraries are being loaded with LD_LEBUG=libs and the output of both of the applications is identical up to the point where one crashes.

Pl45m4

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

This code produces a crash:

#include "pch.h"

static void use_qapp()
{
  QTimer timer(qApp);
}

int main(int argc, char** argv)
{
  // contruct, init FApplication and FGuiRunner
  QApplication qApplication(argc, argv);
  use_qapp();
  return 0;
}

Try to start the event loop (you did not) and check what happens

// replace 
return 0;
// with
return qApplication.exec();

Christian Ehrlicher

Your testcase works fine here and I don't see why it should crash. How do you build your app? With qmake / cmake or manually? Also make sure the correct Qt dlls are picked up and not some old which might be in your PATH env var.

Pl45m4

@Jakob-Kenda

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.