Race condition on window closing when using a threaded renderer

On SailfishOS, I sometimes get a segfault when closing a window. On this platform, a threaded renderer is used, over a Wayland implementation. Here is the backtrace at crash, from the renderer thread:

0xb61e7556 in QMutex::lock() () from /usr/lib/libQt5Core.so.5
(gdb) bt
#0 0xb61e7556 in QMutex::lock() () from /usr/lib/libQt5Core.so.5
#1 0xb3ed03c6 in QWaylandWindow::setCanResize(bool) () from /usr/lib/libQt5WaylandClient.so.5
#2 0xb287291e in QWaylandGLContext::swapBuffers (this=0x72aee0, surface=<optimized out>) at ../../../../hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp:517
#3 0xb6976d12 in QOpenGLContext::swapBuffers(QSurface*) () from /usr/lib/libQt5Gui.so.5
#4 0xb6cff77e in QSGRenderThread::syncAndRender (this=this@entry=0x5c59d8) at scenegraph/qsgthreadedrenderloop.cpp:636
#5 0xb6cfff76 in QSGRenderThread::run (this=0x5c59d8) at scenegraph/qsgthreadedrenderloop.cpp:715

We see that it's crashing in a call to swapBuffers() while accessing some internals of the platform window (here a QWaylandWindow). The issue is that the platform window has been deleted already by the main thread. It is visible by adding a break point in the destructor for instance.

I believe this comes from the fact that the close event is not notifying the rendering thread that the resource are going to be destroyed. Indeed, looking at the code, if the close event is accepted, the close handler in QWindow will destroy the underlying platform window without notifying the QSGRenderer attribute 'windowManager'. This may cause the race condition if the renderer is a QSGThreadedRenderLoop because the platform window may be deleted while the thread is using it.

I propose to correct this issue by notifying the QSGRenderer on a close event using the hide() method (which is supposed to release the resources according to documentation), see patch https://codereview.qt-project.org/#/c/253820/