- 
    Bug 
- 
    Resolution: Done
- 
    P2: Important 
- 
    5.3.2
- 
    None
- 
        a8c74ddcf78604c9038ba2a2bea81e445e4b3c58
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.
- resulted in
- 
                    QTBUG-44885 Date conversion tests fail in QtScript -         
- Closed
 
-         
| For Gerrit Dashboard: QTBUG-43703 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V | 
| 103661,4 | Fix race condition in QDateTime::timeZone() and other methods | 5.5 | qt/qtbase | Status: MERGED | +2 | 0 |