Segmentation fault when exiting when linked against Qt 6.9.1

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

l3u_

First, it was just a QTabBar interface. But over the years, it got more and more complex, and at some point, I learned about QDockWidgets – and I loved them at first sight ;-) The same as the tab bar if you want – but way more if you need it. The possibility to arrange them as you like and need is really nice. This is actually a powerful tool, with a great user experience. QDockWidgets really rock! They do, from time to time, cause some headache (this is actually not the first bug I filed about them ;-) – but they are really cool.

Axel Spoerl

@l3u_
Could you mark this thread as solved, please?

StudentScripter

@Axel-Spoerl Love QDockwidget too, great work <3

I always miss them in QML ( i know that QML is mainly mobile focused but nevertheless). :D

Axel Spoerl

@StudentScripter Not as an immediate priority, but we are planning to implement something like dock widgets also in Quick Controls.

StudentScripter

@Axel-Spoerl Awesome <3 Is it on the near roadmap or will have to wait a few years?

JonB

@StudentScripter Just so you know, @Axel-Spoerl is away atm and won't answer for a week or two...

StudentScripter

@JonB Thanks for the hint, but im in no hurry right now. :D Have a nice day.

Axel Spoerl

Thanks @JonB for notifying!
The dock widget implementation has some obvious limitations, like e.g. permissions: You can limit allowed main window dock areas, but not the permission to dock on a floating dock. You can’t merge floating docks.

That said, we’ll have to take a deeper look and come up with a solid concept for a quick control equivalent. My guess is a year or so. I’ll update this thread in case we have a Jira ticket for input and discussion. In the meanwhile feel free to post ideas here!