Qt6: Current master segfaults on qt-xcb(x11) and qt-wayland qpa on Qt6.4+ #754
Comments
|
Small update with this issue: I filled (potential) QTbug report about this issue (https://bugreports.qt.io/browse/QTBUG-113728) Qt devs replayed: Guessing after a quick look at the code base that you are relying on top-level QWidgets being backed by a QWindow with RasterGLSurface https://doc.qt.io/qt-6/qsurface.html#SurfaceType-enum by default. That type is not used from 6.4 on, rather the window for top-level widgets default to RasterSurface, OpenGLSurface, VulkanSurface, Direct3DSurface, etc. depending on the presence of QOpenGLWidget and QQuickWidget instances within the child hierarchy. Since those are probably not used in your case, the top-level widget is always backed by a RasterSurface QWindow from 6.4 on. So this looks like not QTbug - but rather MythTV incompatibility with Qt6.4+ I'm opened to any ideas/code changes/tests needed to be done to move forward to fix this issue.... |
|
As I recall, at least one related crash is caused by calling initializeOpenGLFunctions before setting a valid OpenGL context (and MythTV does not currently set a valid context). There needs to be a ....->makeCurrent(...surface...) before calling initializeOpenGLFunctions (and perhaps other setup, too). I presume someone fluent in Qt6 and OpenGL would be able to quickly determine what needs to be done. |
|
Problem can be reproduced. |
|
I did have a look at it but I do not think that I can fix this on the short term. |
|
I believe I'm experiencing a similar issue on macOS with QT 6.4 through 6.6 Mythfrontend output and top of the crash report follow: |
|
Yes, the failure on MacOS is identical to that on Linux. I am having another look at it. |
|
I did not get very far on this but is what I did. Attached is a test patch that can be applied to the current master. The result is something that does not crash anymore but now it gives an endless loop of these messages: The basic idea was, as suggested in this thread by the quote from the Qt dev, to change the top level window from a raster surface to an OpenGL surface by inheriting from a QOpenGLWidget instead of a QWidget. Some comments on the code changes in the patch: To get it compiled with qt6 do add the following option to the ./configure command: --qmake=/lib64/qt6/bin/qmake To be able to use the QOpenGLWidget, add the following to the libmythui.pro: And then in mythpainterwindow.cpp/.h the QOpenGLWidget is used instead of the QWidget. There are also a lot of messages added so that the flow through the code can be followed. Suggestions on how to continue with this are welcome! |
|
@kmdewaal - my apologies for just getting around to this. I was waiting on some upstream qt6 fixes to see if anything changed. Like you state, on macOS I'm no longer crashing with myhfrontend. My endless loop statement is similar, but points to Qt: QPainter: While watching mythfrontend load, I did see a picture of my theme for a very brief moment then the screen went black and stayed there with the looping output. |
|
I get this bug on Qt6 6.7.0 (openSUSE Tumbleweed). If I try to debug mythfrontend with gdb, the whole X11 screen freezes. Without gdb, mythfrontend crashes after some seconds: |
|
So I have hit this for awhile and tried to just install 6.3 and compile mythtv there as I run it in a container anyway, but mythtv's min versions is: |
|
I was hoping a bump to qt 6.7 would magically resolve this, unfortunately I'm still getting the same error on macOS 14.6
|
|
OK. I can confirm a few things (at least on linux):
Can anyone confirm this is still not working for them as a solution? |
|
Mitch, This becomes really interesting!
then i applied #984 and test again:
Now: as qt6 6.8.1 seems work for you:
|
|
While I did compile a newer QT version originally to see if that would fix it right now I have defaulted back to the container's os builtin QT version. I am using ubuntu noble (24.04) as my base docker image for mythtv. Ubuntu is using QT 6.4 by default (although one can use aqtinstall for others). I am on x64. As per your questions:
The error discussed here As you seem to follow a set of steps each time, I might try a clean patched build to make sure it isn't using an old object or binary. Personally I am more interested in why more users don't hit this. Given mythTV has required QT 6.4 for quite awhile I can't imagine it is they are using an older QT version. This doesn't sound like a real bug as much as a code change that should have happened from what the QT dev mentioned. Related Logs |
|
About why not more people complain. I think that most people, including me, are still using Qt5 and have not yet switched to Qt6. One possible reason why the fix does work for you is that you are using Nvidia graphics. I did a lot of testing a while ago and I could not get it to work on Fedora 40. Test 1 Today's master, unmodified. As expected, but it is good to have a baseline. Test 2 As test 1 but with patch from #984 applied, so the following code is always executed: Result is crash but different: Test 3 As test 2 but with the code changed to use the RasterGLSurface: Result same as test 2: My tentative conclusion is that the fix does work on Nvidia graphics but not on Intel or embedded platforms. |
|
I think you have hit a 'new' bug essentially. This original bug was 'by design' in terms of that error throwing. Now when you set a surface to use opengl however you crash. You might want to take a look at the QT options for controlling egl: I would probably file a new ticket with QT, and if possible create a simple test program that just creates a surface and sets its type to GL to see if you can easily crash that way. |
|
I'm pretty sure the macOS community doesn't complain about the bug since the build script sets qt5 as default or they're using the prebuilt binaries for which the github CI is uses qt5. I've been wanting to upgrade both to qt6, but this bug has been in the way. Thankfully testing Mitch's suggested fix seems to work on at least on macOS 15 with qt 6.8. |
|
But the minimum to build mythtv has been at 6.4 for awhile. Surely at least developers can launch mythtv master so not sure what systems it would work out of the box on. |
|
FYI: I put some more investigations in https://bugreports.qt.io/browse/QTBUG-113728 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Platform:
MiniMyth2; qt6 build from sources
MythTV version:
current master (tested on v34-Pre-d54bb609dac)
Package version:
Component:
Qt6
What steps will reproduce the bug?
Build myth-master on system with Qt6 newer than 6.3 and run mythtv with drawing to x11 or wayland.
Drawing to eglfs qpa works ok.
As issue:
I suspect issue might be rather related to i.e. https://doc.qt.io/qt-6/opengl-changes-qt6.html starting to manifetst incompatibility between mythtv OpenGL code and Qt6 current OpenGL support?
How often does it reproduce? Is there a required condition?
always
What is the expected behaviour?
correct operation on Qt6.4 and Qt6.5
What do you see instead?
Qt 6.5.0 with drawing to X11 gives me segfault like this: https://gist.github.com/warpme/95abdde87d468ce8cf4bb2416159e6d4
The same binaries (qt6, mythtv) are working ok with drawing to eglfs.
(https://gist.github.com/warpme/cdc7e9a23bca4cb10c0433d880cc288d).
Additional information
I tested following Qt versions:
(each time only qt was rebuild)
The text was updated successfully, but these errors were encountered: