Segmentation fault when exiting when linked against Qt 6.9.1

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 :-)

Axel Spoerl

The fix will land in 6.9.2, which we plan to release on August 14th.

If you want to cherry pick and compile locally, please make sure to pick the following 5 commits in the right order:

l3u_

Nice :-)

I just tried it locally, cherry-picking the exact comments you linked. Worked without a collision on a v6.9.1 checkout.

And – you may already have thought that – I can confirm the segfault is gone now, also for my quite complex use-case :-)

Axel Spoerl

Great that you are using dock widgets! As you may have suspected: QDockWidget is slightly closer to my heart than other creatures in the widget zoo ;-)