Details
Description
The current implementation of QLockFile::unlock() contains a race condition with QLockFilePrivate::getLockInfo(). This leads to situations where the lock file is not deleted even though its owner hasn't crashed. Thus, only stale timeout can resolve the situation later.
Steps to reproduce:
1) Let's take example function void test()
2) Open two Qt Creators with the project.
3) In the first, set breakpoint on line "QFile::remove(d->fileName)" in QLockFile::unlock() and step to it.
4) In the second, set breakpoint on line "QByteArray pidLine = reader.readLine();" in QLockFilePrivate::getLockInfo() and step to it.
5) Let the first debugger run (QFile::remove() will fail. If I called ::DeleteFile(), the last error would be ERROR_SHARING_VIOLATION).
6) Let the second debugger run (it will wait forever).
Possible fix:
Use two files, one empty .lock (for locking) and one .lock.info (containing the metadata).
Attachments
For Gerrit Dashboard: QTBUG-38853 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
94064,4 | QLockFile: on Windows, retry deleting the lock file if it is being read. | 5.4 | qt/qtbase | Status: MERGED | +2 | 0 |