Details
-
Task
-
Resolution: Unresolved
-
P1: Critical
-
None
-
6.9
-
None
Description
An issue was found in Qt Application Manager where it looks like the QWaylandXdgTopLevel object outlives its QWaylandXdgSurface, even though the client is sending the requests in the correct order:
[ 82515.499] xdg_toplevel@28.destroy() [ 82515.511] -> wl_display@1.delete_id(28) [ 82515.519] xdg_surface@27.destroy() [ 82515.531] -> wl_display@1.delete_id(27) [ 82515.539] wl_surface@24.attach(nil, 0, 0) [ 82515.555] wl_surface@24.commit()
When the xdg_toplevel@destroy() is received, the class should call wl_resource_destroy() which in turn should call delete on the QWaylandXdgTopLevel object. This is a pretty standard pattern in Qt Wayland, but there are indications that this does not happen, causing this patch to be needed: https://codereview.qt-project.org/c/qt/qtapplicationmanager/+/603393
While this code did have dangling pointers before and would be prone to crash, the check for m_xdgSurface before accessing the m_topLevel or m_popup there should not be necessary. Just making everything QPointer should suffice.
Since this is hard to reproduce, the issue is also hard to debug. It needs to be investigated further whether the check on m_xdgSurface is actually needed and if so, why.
Attachments
Issue Links
- blocks
-
QTBUG-131312 Top flaky test: qml::ApplicationManager::test_startAndStopApplication
- Reported
- resulted from
-
QTBUG-130869 tst_applicationmanager_multi-process (Failed)
- Reported