Segmentation fault when exiting when linked against Qt 6.9.1

l3u_

Except for some special situations, I don't delete anything by hand, and I also almost never have to use deleteLater … the project has a network stack where I have to mess with this stuff, but at the point the crash happens, none of this code is active.

I really only wonder how I can track this down … and why it happens with 6.9.1, but not with 6.8.3 …

However, I'll check all delete and deleteLater statements I use, thanks for the hint :-)

l3u_

Okay. The only place where I use a delete statement in code that is active is that I remove a lock file in my database backend when I close the connection. That seems to be unrelated to that layout/widget issue, I can as well open a database, close it (and then the delete happens) and I still get a segfault on closing. All deleteLater statements I use happen in classes that aren't even instatiated at this point … so I'm pretty sure that neither a delete statement, nor a deleteLater call happens during closing.

Seems to me it has something to do with the QDockWidgets I use and the QTabBar they are displayed with, no?

I just tried to compile against a local debugging enabled build of Qt 6.9.0 – no crash there. But the crash against 6.9.1 happens every time …

l3u_

I really have no idea why this happens. Neither my MainWindow class, nor any of the QDockWidgets shown even have a destructor, so I don't even have the chance to delete something that should not be deleted …

The MainWindow catches a closeEvent though. I set a break point there and stepped through what happens. The whole function exits like it should. No problem …

The crash happens really late, after everything seems to be already cleaned up:

QCoreApplication::exec ()
    at /home/tobias/Qt/qtbase-everywhere-src-6.9.1/src/corelib/kernel/qcoreapplication.cpp:1450
1450        threadData->quitNow = false;
(gdb) n
1452        if (self)
(gdb) n
1453            self->d_func()->execCleanup();
(gdb) n
1455        return returnCode;
(gdb) n
main (argc=1, argv=0x7fffffffd178) at /home/tobias/tmp/git/muckturnier/src/main.cpp:130
130     }
(gdb) n

Thread 1 "muckturnier" received signal SIGSEGV, Segmentation fault.
0x0000555555a55b76 in removeWidgetRecursively (li=<optimized out>, w=0x5555571eec40)
    at /home/tobias/Qt/qtbase-everywhere-src-6.9.1/src/widgets/kernel/qlayout.cpp:474
474             if (child->widget() == w) {
(gdb) n
[Thread 0x7ffff49e7900 (LWP 10439) exited]
[Thread 0x7ffff45ff6c0 (LWP 10442) exited]
[New process 10439]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

Line 130 of my main.cpp is at the very end, after return application.exec():

129        return application.exec();
130    }
131

Does this help?!

jsulm

@l3u_ You could disable functionality until it does not crash, then you would know which part leads to the crash.

Christian Ehrlicher

@Axel-Spoerl : dockwidgets... 😛

l3u_

The problem is that the only custom thing I do is the closeEvent override – everything else happens inside the default Qt code … and even if I remove the custom closeEvent, the segfault is the same (which is not really surprising, when I stepped through everything that happens, the function returns, and the crash happens way later, while we're long deep inside Qt …).

@Christian-Ehrlicher : May I suppose from what you wrote that this is not the first time strange things happen when dock widgets are messed with?! ;-)

The only thing I can definitely say is that some change from 6.9.0 to 6.9.1 causes this, because it never happens with 6.9.0, and it always happens with 6.9.1 …

l3u_

Luckily, my desktop is still quite decent, so I could git bisect out the commit that introduced this.

If I checkout

commit 19c4db4201e8933fbbbf951809ceff30e99b4458
QDockWidget: don't access a QMainWindow that's under destruction

everything is fine, no crash. One commit later, at

commit ab6f1ad77852a427ae73172ca11dacf876a0cbf7
QMainWindowLayout: Fix leaking of unused tab bars

I get the segfault.

I would call it a regression …

Axel Spoerl

Ooops, I am guilty for the guilty commit!

What's obviously crashing is a QDockWidget. Can you tell us more about those?
How are they added? how is QDockWidget::setWidget() used? In which state are they, when the crash occurs (docked on the main window / Floating / Tabbed)?

l3u_

@Axel-Spoerl Hi, nice to meet the right guy at once ;-)

I meanwhile filed a bug report about this: https://bugreports.qt.io/browse/QTBUG-137755

For all dock widgets I first instatiate a widget, like this (all are simple QWidgets – with quite complex stuff inside, but still):

m_registrationPage = new RegistrationPage(this, m_sharedObjects);
...

then, I create the dock, format it, set the widget and hide it, like this:

m_playersDock = new QDockWidget(tr("Anmeldung"), this);
m_playersDock->setWidget(m_registrationPage);
formatDockWidget(m_playersDock, QStringLiteral("playersDock"));
addDockWidget(Qt::TopDockWidgetArea, m_playersDock);
connect(m_registrationPage, &RegistrationPage::raiseMe, m_playersDock, &QDockWidget::raise);
m_playersDock->hide();

Where the formatting is:

void MainWindow::formatDockWidget(QDockWidget *dock, const QString &id)
{
    dock->setObjectName(id);
    dock->setContextMenuPolicy(Qt::PreventContextMenu);
    dock->setFeatures(QDockWidget::DockWidgetMovable | QDockWidget::DockWidgetFloatable);
}

When I start the program, all docks are hidden. If I close it again in this state, I get no segfault.

Opening a database makes them show up, by default attached to the main window and tabbed. When closing the program then, the segfault happens.

Interestingly, if I close my database again, the docks are hidden again – but still, I get a segfault on closing.

l3u_

Btw. I didn't change this code since Qt 5.6 back in 2017 …

Axel Spoerl

Hm. Looks like I went too far and we have to revert or follow up on this patch.
Can you do me a favor: Report it as a bug, assign it to me? I'll fix it this week.

l3u_

I already filed one here: https://bugreports.qt.io/browse/QTBUG-137755 – I can't assign it to you though (or better said, I don't know how to do that …)

Somebody already commented on it, and mentioned these two PRs:
https://codereview.qt-project.org/c/qt/qtbase/+/637198
https://codereview.qt-project.org/c/qt/qtbase/+/636652

SGaist

@l3u_ done for you :-)

l3u_

Thanks :-)

l3u_

Just to also leave this here: I meanwhile could strip it down to a minimal example producing the crash, cf. the sources attached to https://bugreports.qt.io/browse/QTBUG-137755

Produces the crash reliably when linked against Qt 6.9.1. You have to run the program twice: The first time, it exits normally. The second time, when the window geometry and state are restored, it segfaults on exiting.

No delete, no deleteLater, nothing special at all …

Axel Spoerl

Great reproducer!
Someone decades ago felt like storing unused tab bars for later re-usage in QMainWindowLayout.
Those were soft-leaked and taken care off, when QApplication got destroyed.
Reading the state back from settings causes the original tab bar (created in the C++ part) to become unused, but not removed from its QMainWindow parent. That ultimately lead to a double delete and the crash.
Let's see, if my thorough reviewers let me get away without writing an autotest ;-)

l3u_

Wow, that was fast :-) Thanks for the immediate fix! Nice to see my stuff helped here!

That was quite deep inside Qt apparently … where will this land? Qt 6.10.0? Or will it be backported?

I tried to cherry-pick it to a 6.9.1 checkout to test it, but it seems that's no trivial task …

jsulm

@l3u_ You can see in the bug report:
Fix Version/s: 6.10.0 Beta2, 6.11.0 FF

l3u_

Ah okay. So no 6.9 backport? I just wondered, because in the respective "Change ID" https://codereview.qt-project.org/c/qt/qtbase/+/653727, it's listed: "Fixes: QTBUG-137755 Pick-to: 6.10 6.9"

jsulm

@l3u_ Yes, it looks like it was cherry picked to 6.9 branch, so may end up in some 6.9.x version :-)