QSingleShotTimer instances are usually destroyed when they receive their QTimerEvent, and otherwise are children of the creating thread's event dispatcher so that they do get destroyed even if they never fired. However, if the receiver object lives in a different thread than the thread that started the timer, then we move the QSST instance to that thread to make sure that it starts in the right thread. We then reparented the QSST instance to nullptr (it can't continue to be a child of the creating thread's event dispatcher), and connected to QApp::aboutToQuit as a fall-back in case the timer never fires. This has two problems: if the timer never fires (e.g. because the receiver's thread stopped before the timeout), then we created a soft leak (until aboutToQuit). And since the QSST instance was moved to the receiver's thread, the connection to aboutToQuit() is always queued, and also never got processed if the thread was stopped before (especially since we connected to deleteLater(), which would require another event processing cycle). So in practice, we ended up with a hard leak. To fix this, we have to reparent the QSST instance to the event dispatcher of the receiver's thread. We can do that reliably once the receiver thread processes events. Simplify the code to replace a meta-call with a posted event to ourselves, receiving which starts the timer (or immediately fires timeout if it has taken long enough to get there). To avoid memory leaks in the unlikely case that this posted event never gets delivered (e.g. because the thread is shutting down already), give that event ownership of the QSST instance until the timer is started. This turns out to be leaking anyway on most platforms, which requires further investigation. To be able to reparent safely away from a parent in a different thread, clear the sendChildEvents flag first. Amends 87535e4e4337596066258e361143cb9906e89512. Fixes: QTBUG-135636 Pick-to: 6.9 6.8 Change-Id: I8188160d54cfb63cb1765c5de8a6c0728dabb7e5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>