Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.3.2
-
None
-
a8c74ddcf78604c9038ba2a2bea81e445e4b3c58
Description
As far as I understand there is a race condition in QDateTimePrivate::refreshDateTime.
QDateTimePrivate::refreshDateTime is called by const QDateTime methods. Therfore if there are copies of a QDateTime instance due to COW all point to the same data.
Now when e.g. QDateTime::isValid is called for multiple objects in multiple threads, all pointing to the same data, then the following lines will lead to a race condition.
case Qt::TimeZone: // If already cached then don't need to refresh as tz won't change if (isTimeZoneCached()) return; // Flag that will have a cached result after calculations setTimeZoneCached(); break;
For example:
- Thread A enters QDateTimePrivate::refreshDateTime first and calls setTimeZoneCached()
- Now Thread B enters the function and leaves it again, since the time zone is already marked as cached.
- Thread B uses m_offsetFromUt, though it has not been calculated yet.
- Thread A calculates m_offsetFromUt
Other than that with the way it is handled now there can be issues with cpu caches.
Attachments
Issue Links
- resulted in
-
QTBUG-44885 Date conversion tests fail in QtScript
- Closed