Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-43703

Race Condition in QDateTimePrivate::refreshDateTime

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 5.5.0
    • 5.3.2
    • Core: Date/Time
    • 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:

      1. Thread A enters QDateTimePrivate::refreshDateTime first and calls setTimeZoneCached()
      2. Now Thread B enters the function and leaves it again, since the time zone is already marked as cached.
      3. Thread B uses m_offsetFromUt, though it has not been calculated yet.
      4. 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

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              thiago Thiago Macieira
              mfuchs Matthias Fuchs
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes