Qt 6 application hangs during graphics initialization (RHI/QML or OpenGL/Q3DSurface) with Mesa/llvmpipe software rendering

A C++/QWidget-based application utilizing both QQuickWidget (for QML content, including C++ context properties and image providers) and Q3DSurface (from QtDataVisualization) works correctly under Qt 5.x but exhibits hangs during initialization under multiple Qt 6 versions (tested up to 6.9.0 RC, incl. 6.3, 6.5, 6.8) specifically when using Mesa's llvmpipe software renderer on Linux via RemoteDesktop.

The hangs occur in two distinct scenarios, deep within Mesa/LLVM library functions:

1. Hang during Application Startup (show()/exec()): If the QQuickWidget component is enabled (even if Q3DSurface is disabled), the application hangs when the main window is shown or the event loop starts. The stack trace points towards initialization related to Qt Quick's Rendering Hardware Interface (RHI), likely using its default OpenGL backend, which then invokes Mesa/llvmpipe. (See Stack Trace 1 below).
2. Hang during Q3DSurface Initialization: If the QQuickWidget is disabled but Q3DSurface is enabled, the application hangs specifically when the Q3DSurface object is instantiated or shortly after when its OpenGL context is created (via QOpenGLContext::create()). This happens regardless of whether the initialization is deferred until after the main window is shown. The stack trace points directly to QOpenGLContext::create() calling into Mesa/llvmpipe. (See Stack Trace 2 below).

The application only starts successfully under llvmpipe if both the QQuickWidget and Q3DSurface components are disabled or not initialized.

Testing with X11 forwarding (ssh -Y from Linux to VcXsrv on Windows) produces the exact same hanging behavior, confirming the issue is server-side within the Qt 6 + Mesa/llvmpipe interaction.

Crucial Discrepancy: A minimal test application (see attachment: bug_gl.zip containing .pro and main.cpp and QML) which includes both a QQuickWidget and a Q3DSurface does NOT hang under the same LIBGL_ALWAYS_SOFTWARE=1 conditions. This suggests the hang in the full application is triggered by the interaction of these components with a more complex QWidget UI hierarchy (multiple docks, tabs, toolbars, menus etc. created via setupUi), specific QML bindings (setContextProperty, addImageProvider), application state, or initialization timing.

Steps to Reproduce:

1. Use a Linux system with Mesa drivers (Ubuntu, client glx vendor string: Mesa Project and SGI, client glx version string: 1.4).
2. Build and run a sufficiently complex Qt 6 (e.g., 6.7.2, 6.9.0 RC) application containing both a QQuickWidget and a Q3DSurface, similar in structure to the user's failing application (complex main window with docks/tabs).
3. Test 1: Enable only the QQuickWidget. Observe hang during startup (likely show() or exec()).
4. Test 2: Disable QQuickWidget, enable Q3DSurface (potentially with deferred initialization). Observe hang during Q3DSurface context creation.
5. (Optional): Build and run the attached minimal example under the same conditions. Observe that it does not hang, highlighting the complexity requirement.

Actual Results: Application hangs indefinitely during graphics context initialization within Mesa/llvmpipe library calls (stack traces involve LLVM functions).

Expected Results: Application should start and run (potentially slowly due to software rendering) without hanging, as it did in Qt 5.x. Error messages might be acceptable if context creation fails cleanly, but a hard hang is a regression.

Stack Traces:

(Labelled based on previous conversation)

Stack Trace 1 (Likely QML/RHI related hang during show()/exec()):

1 llvm::ValueSymbolTable::makeUniqueName(llvm::Value *, llvm::SmallString<256u>&) 0x7fff8359963c
2 llvm::ValueSymbolTable::createValueName(llvm::StringRef, llvm::Value *) 0x7fff835998c4
3 llvm::Value::setNameImpl(llvm::Twine const&) 0x7fff83595d67
4 llvm::Value::setName(llvm::Twine const&) 0x7fff83595da9
5 ?? 0x7fff834b11e5
6 LLVMBuildGEP 0x7fff834b10dc
7 ?? 0x7fff8d5dd727
8 ?? 0x7fff8d5e1b88
9 ?? 0x7fff8d5d3438
10 ?? 0x7fff8d5b99d0
11 ?? 0x7fff8d017863
12 ?? 0x7fffb7afc2db
13 ?? 0x7fffb7afd3ff
14 QRhi::endOffscreenFrame(QFlags<QRhi::EndFrameFlag>) 0x7fffb7996a2b
15 QQuickRenderControl::endFrame() 0x7fffb89362c1
16 QWidget::event(QEvent *) 0x7fffb818c311
17 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7fffb81344f2
18 QCoreApplication::notifyInternal2(QObject *, QEvent *) 0x7fffb6a4c18a
19 QWidgetPrivate::sendPendingMoveAndResizeEvents(bool, bool) 0x7fffb818350e
20 QWidgetPrivate::show_helper() 0x7fffb818b303
21 QWidgetPrivate::setVisible(bool) 0x7fffb818a883
// ... many showChildren/show_helper calls ...
36 QWidgetPrivate::setVisible(bool) 0x7fffb818a883
37 main main.cpp 78 0x55555558e67d

Stack Trace 2 (Q3DSurface related hang during explicit initialization):

1 llvm::raw_ostream::~raw_ostream() 0x7fff49fe4240
2 llvm::ValueSymbolTable::makeUniqueName(llvm::Value *, llvm::SmallString<256u>&) 0x7fff4a1766a0
3 llvm::ValueSymbolTable::createValueName(llvm::StringRef, llvm::Value *) 0x7fff4a1768c4
4 llvm::Value::setNameImpl(llvm::Twine const&) 0x7fff4a172d67
5 llvm::Value::setName(llvm::Twine const&) 0x7fff4a172da9
6 ?? 0x7fff4a08e1e5
7 LLVMBuildGEP 0x7fff4a08e0dc
// ... many ?? frames likely within Mesa/LLVM ...
30 ?? 0x7fff9477783b
31 ?? 0x7fff947792cd
32 QOpenGLContext::create() 0x7fffb7ae2c81
33 QAbstract3DGraph::QAbstract3DGraph(QAbstract3DGraphPrivate *, QSurfaceFormat const *, QWindow *) 0x7fffb8ef1695
34 Q3DSurface::Q3DSurface(QSurfaceFormat const *, QWindow *) 0x7fffb8eef1f7
35 SurfaceGraph::initialize surfacegraph.cpp 66 0x5555555e577f
36 LandscapeVisualization::setup landscapevisualization.cpp 57 0x5555555fa72e
37 MainWindow::modelStateChanged mainwindow.cpp 136 0x5555555ab7cf
// ... signal/slot propagation ...
57 main main.cpp 74 0x55555558e4bc

Workaround(s):

• Disable both QQuickWidget and Q3DSurface components when running with software rendering.

Attachment: bug_gl.zip (containing .pro and main.cpp with QML).