Fix race in QFseventsFileSystemWatcher destructor
The race goes like this: 1) We destruct QFseventsFileSystemWatcher, which calls FSEventStreamStop and FSEventStreamInvalidate/FSEventStreamRelease 2) The FSEvent* calls will happen on the same thread as the destructor is being called on, which will be different to the thread that the FSEvent* events are popping out on. 3) So, there could be a case where we are in the middle of processing an event, but the QFseventsFileSystemWatcher has already died. The fix is to dispatch the stop/invalidate/release on the queue associated with the stream. Patch by Matt Galloway! Fixes: QTBUG-85594 Change-Id: Ie168bbe91e55c5559632b37bc008e11597e4fdaf Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> (cherry picked from commit 6533d1a47309956e8acda90eb4c41d245e817c93) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This commit is contained in:
parent
47a842ee0c
commit
a6699dd0df
@ -310,14 +310,16 @@ QFseventsFileSystemWatcherEngine::~QFseventsFileSystemWatcherEngine()
|
|||||||
{
|
{
|
||||||
QMacAutoReleasePool pool;
|
QMacAutoReleasePool pool;
|
||||||
|
|
||||||
// Stop the stream in case we have to wait for the lock below to be acquired.
|
dispatch_sync(queue, ^{
|
||||||
if (stream)
|
// Stop the stream in case we have to wait for the lock below to be acquired.
|
||||||
FSEventStreamStop(stream);
|
if (stream)
|
||||||
|
FSEventStreamStop(stream);
|
||||||
|
|
||||||
// The assumption with the locking strategy is that this class cannot and will not be subclassed!
|
// The assumption with the locking strategy is that this class cannot and will not be subclassed!
|
||||||
QMutexLocker locker(&lock);
|
QMutexLocker locker(&lock);
|
||||||
|
|
||||||
stopStream(true);
|
stopStream(true);
|
||||||
|
});
|
||||||
dispatch_release(queue);
|
dispatch_release(queue);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user