1. 01 Feb, 2018 - 4 commits
    • Thiago Macieira's avatar
      Revert "QVariant: convert QDateTime and QTime to string with milliseconds" · 69d2501e
      Thiago Macieira authored
      This reverts commit ab1e5075
      
      . That was
      supposed to be a minor behavior change, but ends up having visible
      effects such as QtXmlPatterns xs:dateTime type now reporting sub-second
      fractions. So we're reverting in 5.10 and re-applying in 5.11.
      
      Change-Id: I741e49459c9a688c1c329d6cbd521cd4a0b2aa84
      Reviewed-by: default avatarLars Knoll <lars.knoll@qt.io>
      69d2501e
    • Christian Strømme's avatar
      Android: Don't rely on QDir::homePath() to get the application directory · eadf9e54
      Christian Strømme authored
      
      If the QLoggingRegistry gets called as part of the static initialization
      phase, it would call into Android's QStandarPaths implementation, which
      assumed that the HOME env. variable was already set. Since the variable
      isn't set before main is called, QDir::homePath() returns the root path,
      which would be cached and always returned.
      
      With this fix we now call Android's getFilesDir() directly, which will
      always return the right path. Since the font locations are also relying
      on an environment variable being set, we no longer cache that either.
      
      Task-number: QTBUG-65820
      Change-Id: If45f3d5f0e87b808a62118ae95c31b492885646a
      Reviewed-by: default avatarTor Arne Vestbø <tor.arne.vestbo@qt.io>
      Reviewed-by: default avatarEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
      eadf9e54
    • Tor Arne Vestbø's avatar
      Android: Defer initialization of logging rules until qApp construction · 538b1b50
      Tor Arne Vestbø authored
      On Android, we load the application library, and its dependencies (Qt),
      on Android's main thread (thread 0), and then spin up a secondary
      thread (thread 1), that we call main() on.
      
      If any QObject is constructed during loading of the application library
      or any of Qt's libraries, via static initializers or constructor
      functions, we will set QCoreApplicationPrivate::theMainThread to
      thread 0, which will confuse Qt later on when it's being run on
      thread 1, and will result in a warning during QCoreApplication
      construction:
      
       QApplication was not created in the main() thread
      
      This situation can easily lead to a crash as well.
      
      Unfortunately logging via qDebug/qCDebug and friends will trigger
      this too, as they internally use QObject.
      
      Fixing the root cause of this is under investigation, but for now
      we will partially revert fa2a653b for Android. The effect
      is that any qCDebug with a "qt.*" category before qApp construction
      will turn into a no-op, like it was before fa2a653b.
      
      This patch does not cover the case of a regular qDebug, or a qCDebug
      with a non-Qt category. Those will still produce the same symptom,
      as before fa2a653b
      
      .
      
      Task-number: QTBUG-65863
      Change-Id: I95675731d233244530d0a2a1c82a9578d5599775
      Reviewed-by: default avatarEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
      Reviewed-by: default avatarTor Arne Vestbø <tor.arne.vestbo@qt.io>
      538b1b50
    • Tor Arne Vestbø's avatar
      macOS: Handle update requests via setNeedsDisplay more carefully · 7d1962ca
      Tor Arne Vestbø authored
      
      Instead of trying to detect situations where we need to send a real
      expose event instead of an update request in response to a drawRect
      call, we keep track of when we've asked the view to display due to
      a requestUpdate call, and only deliver the corresponding drawRect
      as an update request if no other code has asked the view to
      display.
      
      This should cover all cases of asking the view to display, issued
      from our code or from AppKit, such as the view changing its backing
      scale factor, or otherwise needing a real expose event.
      
      Task-number: QTBUG-65663
      Change-Id: I1783787823aee889dad8e48f34a1cb0f1b7b06bd
      Reviewed-by: default avatarShawn Rutledge <shawn.rutledge@qt.io>
      7d1962ca
  2. 26 Jan, 2018 - 2 commits
  3. 25 Jan, 2018 - 9 commits
  4. 24 Jan, 2018 - 12 commits
  5. 23 Jan, 2018 - 3 commits
  6. 22 Jan, 2018 - 6 commits
  7. 20 Jan, 2018 - 3 commits
  8. 19 Jan, 2018 - 1 commit
    • Andre de la Rocha's avatar
      Handle OOM condition in the validation of plugin metadata · e211ab76
      Andre de la Rocha authored
      
      A large plugin dll (e.g., one with many MB of debug info) could cause
      a 32-bit application to crash when the entire dll file could not fit
      within the address space of the process. The code for validating a
      plugin library and retrieving metadata from it first tried to map
      the entire file in memory, which failed for large files, returning
      NULL. In this case, the code tried then to read the entire file via
      QFile::readAll(), which deep below caused a bad_alloc exception in
      malloc, resulting in the termination of the application. This change
      handles the case where the library could not be mapped into memory,
      in spite of memory mapping being supported, by reporting the error
      and returning false, making the plugin unavailable.
      
      [ChangeLog][QtCore][QPluginLoader] Fixed a bug that would cause the
      Qt plugin scanning system to allocate too much memory and possibly
      crash the process.
      
      Task-number: QTBUG-65197
      Change-Id: I8c7235d86175c9fcd2b87fcb1151570da9b9ebe3
      Reviewed-by: default avatarJan Arve Sæther <jan-arve.saether@qt.io>
      e211ab76