Basic application crashes in QGuiApplication constructor if QCoreApplication::instance is called.

Jakob Kenda

This is a minimal reproducible example.

It's a really simple Qt application that constructs a QGuiApplication and then tries to output QGuiApplication::applicationDisplayName.
There are two versions - one that crashes and one that doesn't:

$ cat crash.cpp
#include "QtGui/qguiapplication.h"
#include "QtCore/qdebug.h"

int main(int argc, char** argv)
{
        QGuiApplication app(argc, argv);
        qDebug() << qApp->applicationDisplayName();
}
$ cat nocrash.cpp
#include "QtGui/qguiapplication.h"
#include "QtCore/qdebug.h"

int main(int argc, char** argv)
{
        QGuiApplication app(argc, argv);
        qDebug() << app.applicationDisplayName();
}

They are compiled using a simple Makefile:

$ cat Makefile
CXX=g++ -std=c++23

Qt6_DIR=${HOME}/Qt/6.10.1/gcc_64
Qt6_LIBS=-lQt6Core -lQt6Gui

QT_INCLUDE=-I${Qt6_DIR}/include -L${Qt6_DIR}/lib
QT_LINK=${Qt6_LIBS}

.PHONY: all clean

all: crash nocrash

crash: crash.cpp
        ${CXX} ${QT_INCLUDE} -o crash crash.cpp ${QT_LINK}

nocrash: nocrash.cpp
        ${CXX} ${QT_INCLUDE} -o nocrash nocrash.cpp ${QT_LINK}

clean:
        rm -f crash nocrash

Compiling and executing the applications:

$ make -j2
g++ -std=c++23 -I/Qt/6.10.1/gcc_64/include -L/home/jakobk/Qt/6.10.1/gcc_64/lib -o crash crash.cpp -lQt6Core -lQt6Gui
g++ -std=c++23 -I/Qt/6.10.1/gcc_64/include -L/home/jakobk/Qt/6.10.1/gcc_64/lib -o nocrash nocrash.cpp -lQt6Core -lQt6Gui
$ LD_LIBRARY_PATH=/Qt/6.10.1/gcc_64/lib ./crash
Segmentation fault (core dumped)
$ LD_LIBRARY_PATH=~/Qt/6.10.1/gcc_64/lib ./nocrash
"nocrash"

To me, this looks like a bug in Qt. Am I missing something?
The reason I'm not sure is that both versions work fine when compiled with CMake using find_package:

cmake_minimum_required(VERSION 3.16)
project(qt-crash-minimal)

set(Qt6_DIR ~/Qt/6.10.1/gcc_64/lib/cmake/Qt6)
find_package(Qt6 REQUIRED COMPONENTS Core Gui)

add_library(qt INTERFACE)
target_link_libraries(qt INTERFACE Qt::Core Qt::Gui)

add_executable(crash crash.cpp)
target_link_libraries(crash PUBLIC qt)

add_executable(nocrash nocrash.cpp)
target_link_libraries(nocrash PUBLIC qt)

$ ./crash
"crash"
$ ./nocrash
"nocrash"

In my opinion there shouldn't be a difference in Qt's behaviour whether it's compiled with CMake or "manually" so this must be a bug in Qt.

Jakob Kenda

Turns out I was missing the -fPIC flag when compiling the executable. Now the application runs as expected (like it does on Windows). I guess I now have to use -fPIC everywhere or compile Qt with no-direct-extern-access on.

hskoglund

If you omit the "-std=c++23 -" spec when compiling manually, does it still crash?

Jakob Kenda

Yes.

$ make -j2
g++ -I/Qt/6.10.1/gcc_64/include -L/Qt/6.10.1/gcc_64/lib -o crash crash.cpp -lQt6Core -lQt6Gui
g++ -I/Qt/6.10.1/gcc_64/include -L/Qt/6.10.1/gcc_64/lib -o nocrash nocrash.cpp -lQt6Core -lQt6Gui
$ LD_LIBRARY_PATH=~/Qt/6.10.1/gcc_64/lib ./crash
Segmentation fault (core dumped)

Here's the backtrace from GDB:

#0  doActivate<false> (sender=0x0, signal_index=9, argv=0x7fffffffd3d0) at /home/qt/work/qt/qtbase/src/corelib/kernel/qobject.cpp:4137
#1  0x00007ffff79e0867 in QMetaObject::activate (sender=<optimized out>, m=m@entry=0x7ffff76bb2a0 <QGuiApplication::staticMetaObject>, local_signal_index=local_signal_index@entry=1,
    argv=argv@entry=0x7fffffffd3d0) at /home/qt/work/qt/qtbase/src/corelib/kernel/qobject.cpp:4317
#2  0x00007ffff6ddef16 in QMetaObject::activate<void, QScreen*> (ret=0x0, local_signal_index=1, mo=0x7ffff76bb2a0 <QGuiApplication::staticMetaObject>, sender=<optimized out>)
    at /home/qt/work/qt/qtbase/src/corelib/kernel/qobjectdefs.h:319
#3  QGuiApplication::screenAdded (this=<optimized out>, _t1=<optimized out>) at /home/qt/work/qt/qtbase_build/src/gui/Gui_autogen/include/moc_qguiapplication.cpp:303
#4  0x00007ffff6e5d05f in QWindowSystemInterface::handleScreenAdded (platformScreen=platformScreen@entry=0x555555595ae0, isPrimary=isPrimary@entry=false)
    at /home/qt/work/qt/qtbase/src/gui/kernel/qwindowsysteminterface.cpp:730
#5  0x00007ffff371674c in QtWaylandClient::QWaylandDisplay::handleScreenInitialized (this=0x555555589ee0, screen=<optimized out>, screen@entry=0x555555595ae0)
    at /home/qt/work/qt/qtbase/src/plugins/platforms/wayland/qwaylanddisplay.cpp:609
#6  0x00007ffff373fae3 in QtWaylandClient::QWaylandScreen::maybeInitialize (this=0x555555595ae0) at /home/qt/work/qt/qtbase/src/plugins/platforms/wayland/qwaylandscreen.cpp:82
#7  QtWaylandClient::QWaylandScreen::maybeInitialize (this=0x555555595ae0) at /home/qt/work/qt/qtbase/src/plugins/platforms/wayland/qwaylandscreen.cpp:73
#8  0x00007ffff3659b16 in ffi_call_unix64 () at ../src/x86/unix64.S:104
#9  0x00007ffff36563ef in ffi_call_int (cif=cif@entry=0x7fffffffd610, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=closure@entry=0x0) at ../src/x86/ffi64.c:673
#10 0x00007ffff36590be in ffi_call (cif=0x7fffffffd610, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>) at ../src/x86/ffi64.c:710
#11 0x00007ffff3664bfe in ?? () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#12 0x00007ffff3665473 in ?? () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#13 0x00007ffff366571c in wl_display_dispatch_queue_pending () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#14 0x00007ffff366850f in wl_display_roundtrip_queue () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#15 0x00007ffff37156d8 in QtWaylandClient::QWaylandDisplay::initialize (this=0x555555589ee0) at /home/qt/work/qt/qtbase/src/plugins/platforms/wayland/qwaylanddisplay.cpp:399
#16 QtWaylandClient::QWaylandDisplay::initialize (this=0x555555589ee0) at /home/qt/work/qt/qtbase/src/plugins/platforms/wayland/qwaylanddisplay.cpp:388
#17 0x00007ffff373845d in QtWaylandClient::QWaylandIntegration::init (this=this@entry=0x555555593370) at /home/qt/work/qt/qtbase/src/plugins/platforms/wayland/qwaylandintegration.cpp:108
#18 0x00007ffff7fa7389 in QtWaylandClient::QWaylandIntegrationPlugin::create (this=<optimized out>, system=..., paramList=...) at /home/qt/work/qt/qtbase/src/plugins/platforms/wayland/main.cpp:33
#19 0x00007ffff6de4b1f in init_platform (pluginNamesWithArguments=..., platformPluginPath=..., platformThemeName=..., argc=@0x7fffffffdffc: 1, argv=argv@entry=0x7fffffffe1a8)
    at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1308
#20 0x00007ffff6de82a7 in QGuiApplicationPrivate::createPlatformIntegration (this=0x555555581140) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1590
#21 0x00007ffff6de8d18 in QGuiApplicationPrivate::createEventDispatcher (this=<optimized out>) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1608
#22 0x00007ffff798b071 in QCoreApplicationPrivate::init (this=this@entry=0x555555581140) at /home/qt/work/qt/qtbase/src/corelib/kernel/qcoreapplication.cpp:865
#23 0x00007ffff6debd15 in QGuiApplicationPrivate::init (this=0x555555581140) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.cpp:1636
#24 0x00007ffff6ded524 in QGuiApplication::QGuiApplication (this=0x7fffffffe010, argc=@0x7fffffffdffc: 1, argv=0x7fffffffe1a8) at /home/qt/work/qt/qtbase/src/gui/kernel/qguiapplication.h:175
#25 0x00005555555552d4 in main ()

Looks like a null pointer dereference to me (sender in doActivate is 0).

Christian Ehrlicher

@Jakob-Kenda said in Basic application crashes in QGuiApplication constructor if QCoreApplication::instance is called.:

LD_LIBRARY_PATH=/Qt/6.10.1/gcc_64/lib ./crash

You are missing a tilde here

Jakob Kenda

@Christian-Ehrlicher No, that was just me not wanting to put the path to my home directory on here for some reason. That wouldn't result in a crash but in an error while loading shared libraries message.

jsulm

@Jakob-Kenda Maybe because of https://doc.qt.io/qt-6/qguiapplication.html#qGuiApp vs https://doc.qt.io/qt-6/qapplication.html#qApp ?

JonB

@Jakob-Kenda said in Basic application crashes in QGuiApplication constructor if QCoreApplication::instance is called.:

To me, this looks like a bug in Qt. Am I missing something?

Why do people start out with "this looks like a Qt bug"? 99% of the time it's your code. As @jsulm points out the docs state:

qApp

A global pointer referring to the unique application object. It is equivalent to QCoreApplication::instance(), but cast as a QApplication pointer, so only valid when the unique application object is a QApplication.

Since you don't have a QApplication, qApp will be nullptr, which you could easily test before dereferencing and then wondering why there is a crash. Not meaning to be rude, just saying RTFM ;-)

Jakob Kenda

@JonB @jsulm It's true that I'm creating a QGuiApplication and thus technically using qApp wrong but if that were the main problem then the application built with CMake would be crashing too. At one point I had a QApplication there but I wanted to get rid of as many dependencies as possible (for instance QtWidgets) so I used QGuiApplication instead of QApplication and I guess I overlooked qApp.

Substatuting either QGuiApplication for QApplication or qApp for qGuiApp yields the same result - a crash in the QGuiApplication constructor.

JonB

@Jakob-Kenda said in Basic application crashes in QGuiApplication constructor if QCoreApplication::instance is called.:

Substatuting either QGuiApplication for QApplication or qApp for qGuiApp yields the same result - a crash in the QGuiApplication constructor.

If you really mean this can you provide a crashing example (verbatim repro code + crash stack trace) which does not use QGuiApplication + qApp->, which we know should crash.... You say

        QGuiApplication app(argc, argv);
        qDebug() << app.applicationDisplayName();

works fine, so....?

Jakob Kenda

Turns out I was missing the -fPIC flag when compiling the executable. Now the application runs as expected (like it does on Windows). I guess I now have to use -fPIC everywhere or compile Qt with no-direct-extern-access on.

Jakob Kenda

@JonB said in Basic application crashes in QGuiApplication constructor if QCoreApplication::instance is called.:

which we know should crash

        QGuiApplication app(argc, argv);
        qDebug() << qGuiApp->applicationDisplayName();

shouldn't crash.