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

          For Gerrit Dashboard: QTBUG-43703
          # Subject Branch Project Status CR V

          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