Skip to content
GitLab
Select Git revision
  • dev default
  • 6.2
  • 6.2.2
  • 5.12.12
  • 5.12
  • 6.1
  • 6.2.1
  • 6.2.0
  • 6.1.3
  • 6.0
  • 6.1.2
  • 6.1.1
  • 5.12.11
  • 6.1.0
  • 5.15
  • 6.0.0
  • 5.15.2
  • 5.12.10
  • 5.15.1
  • 5.12.9
  • v5.15.0-alpha1
  • v5.12.7
  • v5.14.1
  • v5.9.9
  • v5.14.0
  • v5.14.0-rc2
  • v5.14.0-rc1
  • v5.12.6
  • v5.14.0-beta3
  • v5.13.2
  • v5.14.0-beta2
  • v5.14.0-beta1
  • v5.14.0-alpha1
  • v5.12.5
  • v5.13.1
  • v5.13.0
  • v5.13.0-rc3
  • v5.12.4
  • v5.13.0-rc2
  • v5.13.0-rc1
  1. 03 Dec, 2019 - 1 commit
  3. 25 Nov, 2019 - 1 commit
  5. 23 Aug, 2019 - 2 commits
    • Mårten Nordheim's avatar
      DBus: fix deadlock when destroying QDBusServer · 2ed7831f
      Mårten Nordheim authored 
      
Observed infrequently in the QDBus tests, it would deadlock when
destroying QDBusServer at the same time as qDBusNewConnection was being
executed as they were locking the same locks, but in opposite order.

QDBusServer locks d->lock, then QDBusConnectionManager::instance()->mutex.
While qDBusNewConnection locks QDBusConnectionManager::instance()->mutex,
then serverConnection->lock (and serverConnection here
is QDBusServer's d-pointer).

QOrderedMutexLocker cannot be used in this situation because it
operates on QMutex*, which d->lock (QReadWriteLock) is not.

Change the code to lock QDBusConnectionManager's mutex before d->lock
and then unlock the QMutexLocker where it would previously destruct.
If QDBusConnectionManager has already been destroyed then we pass a
nullptr to the QMutexLocker which is fine and will not do anything.

Fixes: QTBUG-74635
Change-Id: I7f02d7759da67377996ef042c81b0969ccb8aadb
Reviewed-by: default avatarMarc Mutz <marc.mutz@kdab.com>
Reviewed-by: default avatarEdward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit 6d3a4546)
      2ed7831f
    • Mårten Nordheim's avatar
      Blacklist tst_QDnsLookup::lookup in ci · 8f9120d4
      Mårten Nordheim authored 
      
It is incredibly flaky in CI (all/multiple platforms), but stable on
local machines.

This is not a cherry-pick because it would have to cherry-pick multiple
patches.

Change-Id: Ic1c3887a3c04bbfaa92421fff347161c9bf2ad96
Reviewed-by: default avatarVolker Hilsheimer <volker.hilsheimer@qt.io>
      8f9120d4
  7. 07 Aug, 2019 - 1 commit
    • Tor Arne Vestbø's avatar
      iOS: Disable C++17 · 88b1dd29
      Tor Arne Vestbø authored 
      
The standard library on some of the deployment targets (iOS 8 to 10)
does not have aligned new and delete operators. Allowing C++17 would
make us think we could use those, and the build would fail with the
aligned-allocation-unavailable diagnostic.

Fixes: QTBUG-77197
Change-Id: I86dc1dc97929b0c9359b4d7cc8dbca85672111dc
Reviewed-by: default avatarSimon Hausmann <simon.hausmann@qt.io>
      88b1dd29
  9. 02 Aug, 2019 - 1 commit
  11. 31 Jul, 2019 - 1 commit
  13. 30 Jul, 2019 - 1 commit
  15. 09 Jul, 2019 - 1 commit
  17. 08 Jul, 2019 - 1 commit
  19. 30 Jun, 2019 - 2 commits
    • Marc Mutz's avatar
      QMutexPool: fix memory order of atomic operations · da38f0d6
      Marc Mutz authored 
      
The array of QAtomicPointer<QMutex> can be initialized using relaxed
stores of nullptr, since nullptr is the whole data. But once we store
an actual QMutex pointer in the array, we need to publish the indirect
data thus created. We did this, with testAndSetRelease(); what was
missing was a corresponding acquire fence on load, without which there
is no happens-before relationship between the writes performed by the
QMutex ctor and the reads performed by a subsequent mutex.lock(), say,
on the same data.

Fix by adding acquire fences to all loads. That includes the dtor,
since mutexes may have been created in different threads, and never
been imported into this_thread before the dtor is running.

As a drive-by, return a new'ed QMutex that was successfully installed
directly to the caller, without again going through a load-acquire.

Change-Id: Ia25d205b1127c8c4de0979cef997d1a88123c5c3
Reviewed-by: default avatarDavid Faure <david.faure@kdab.com>
Reviewed-by: default avatarGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: default avatarThiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 65b8f59e)
      da38f0d6
    • Marc Mutz's avatar
      QFreeList: fix memory order on block deletion · 51bcc7e0
      Marc Mutz authored 
      
Blocks are likely to have been created in a differnt thread from the one
performing their deletion, so we need an acquire fence.

The rest of the atomics use in the class looks ok, but nevertheless warrants
a deeper analysis.

Change-Id: I1571ded3a06695b0d58b5bf1d80d6283ac21f959
Reviewed-by: default avatarThiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 6fa34930)
      51bcc7e0
  21. 24 Jun, 2019 - 2 commits
    • Marc Mutz's avatar
      QSimpleTextCodec: fix load memory order of atomic pointer · 4cc6e141
      Marc Mutz authored 
      
The pointer value is not the only data we're interested in, but
instead points to indirect data, so we need a release fence on store
(present) and a corresponding acquire fence on load (was missing).

Change-Id: I51f8251c0c7f4056192880430f2be5e0836dbed6
Reviewed-by: default avatarThiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 6f848290)
      4cc6e141
    • Marc Mutz's avatar
      Optimize and fix handling of QtMessageHandlers · ea16c860
      Marc Mutz authored 
      
A function may almost always have static storage duration, but that
does not necessarily mean that we can store and load pointers to them
without memory ordering. Play it safe and use store-release and
load-acquire for them (which combines to ordered for the fetchAndSet
call in qInstall*Handler(), as we don't know what the caller will do
with the returned function pointer).

Also change the initial value of the atomic pointer to nullptr.
Nullptr already signified the default handler in qInstall*Handler(),
so the API doesn't change. But by using nullptr to mean default, we
place these variables in the BSS segment instead of TEXT, save dynamic
init, or at least a relocation, and we dodge the smelly comparison of
function pointers, using comparison against nullptr instead.

Also, as a drive-by, put the call to ungrabMessageHandler() in a
scope-guard. Both the message handler, as well as the Qt code calling
it (toLocal8Bit()!), may throw, and that would stop all further
logging. In Qt 5.9, we can't use qScopeGuard(), yet, so use a local
struct calling ungrabMessageHandler() in its dtor.

The code still has one problem: When a logging action is underway, and
another thread exchanges the message handler, we might still execute
code in the old handler. This is probably not a problem in practice,
since no-one will use a dynamically-compiled function for logging
(right? :), but should probably be documented or fixed. This patch
does not address this issue, though.

Change-Id: I21aa907288b9c8c6646787b4001002d145b114a5
Reviewed-by: default avatarThiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit cd401b74)
      ea16c860
  23. 25 Jun, 2019 - 1 commit
  25. 24 Jun, 2019 - 2 commits
  27. 23 May, 2019 - 1 commit
  29. 25 Apr, 2019 - 1 commit
  31. 09 Apr, 2019 - 1 commit
  33. 22 Jan, 2019 - 1 commit
  35. 25 Dec, 2018 - 1 commit
  37. 17 Dec, 2018 - 1 commit
  39. 13 Dec, 2018 - 1 commit
  41. 10 Dec, 2018 - 1 commit
  43. 08 Dec, 2018 - 1 commit
  45. 07 Dec, 2018 - 1 commit
  47. 27 Nov, 2018 - 1 commit
  49. 19 Nov, 2018 - 4 commits
  51. 15 Nov, 2018 - 1 commit
  53. 14 Nov, 2018 - 1 commit
    • Oswald Buddenhagen's avatar
      qmake: make sure 'move' commands to DESTDIR are valid on mingw · 56c92b1e
      Oswald Buddenhagen authored 
      
the code ensures that the path ends with a path separator, which is
unhealthy under mingw when the command ends with that path, because it's
interpreted as a line continuation.
the easiest fix is just duplicating the name of the moved file to the
destination side.
the cleaner fix would have been cleaning up the path separator mess, but
that's a more invasive change and doesn't seem worth it.

Task-number: QTBUG-69255
Change-Id: I338f8997b84ed7049b5665872dd25f90b9d4d16a
Reviewed-by: default avatarJoerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit da4dcc08)
      56c92b1e
  55. 12 Nov, 2018 - 1 commit
    • Andy Shaw's avatar
      Windows: Don't output a warning when sHGetKnownFolderPath fails · b731a275
      Andy Shaw authored 
      
In the rare case where the known locations for the standard paths are
not known (such as when an application is used without a user logged
in), it will output a warning to indicate this. In the case of the
GenericConfigLocation, this can mean that it will hang due to the fact
that QLoggingCategory is looking for that location too before it can
output anything.

Therefore, the warning output is removed so that if this part fails it
doesn't cause it to hang as a result.

Change-Id: I4f189361899bd1f868292f30c09fbe50982d2288
Reviewed-by: default avatarKai Koehne <kai.koehne@qt.io>
(cherry picked from commit bebae373)
      b731a275
  57. 08 Nov, 2018 - 1 commit
  59. 07 Nov, 2018 - 1 commit
  61. 03 Nov, 2018 - 1 commit
    • Thiago Macieira's avatar
      Fix deleting of QSharedPointer internals in case QPointer loses the race · 928e77fa
      Thiago Macieira authored 
      
QPointer uses QWeakPointer / QSharedPointer internals in QObject and has
the code to make sure two threads won't stomp on each other if both try
to create a QPointer for the same QObject at the same time. The
threading code was fine, but had a mistake in the clean up code for the
loser thread: the QtSharedPointer::ExternalRefCountData destructor has a
Q_ASSERT for the state of the reference counts. So we need to set the
state correctly before calling the destructor.

But we don't want to do it in case the Q_ASSERT compiled to nothing. So
we use a hack that violates the Second Rule of Q_ASSERTs: don't do
something with side-effects. This way, we can insert code that will only
be compiled if Q_ASSERTs do something, without having to duplicate the
preprocessor conditions from qglobal.h.

Fixes: QTBUG-71412
Change-Id: I1bd327aeaf73421a8ec5fffd1560fdfc8b73b70c
Reviewed-by: default avatarRomain Pokrzywka <romain.pokrzywka@gmail.com>
Reviewed-by: default avatarJędrzej Nowacki <jedrzej.nowacki@qt.io>
(cherry picked from commit 3b8075de)
      928e77fa
  63. 30 Oct, 2018 - 1 commit
    • Michael Brüning's avatar
      [cocoa] Disable offline renderers for dual AMD FirePro GPU · e73bd4a5
      Michael Brüning authored 
      
The AMD FirePro dual gpus on the MacPro have a problem with offline
renderers in Chromium. Therefore, Chromium and thus Qt WebEngine
disable this option via the pixel format attributes.

The Qt Cocoa plugin on the other hand enables it in the recent versions,
causing context creation in Qt WebEngine to fail when run on a MacPro
with dual AMD FirePro gpus due to incompatible context options.

This patch uses the environment variable QT_MAC_PRO_WEBENGINE_WORKAROUND
which is set by Qt WebEngine upon application startup if the application
is running on a late 2013 Mac Pro.

[ChangeLog] Offline renderers will be disabled when the application is
using Qt WebEngine and running on one of the late 2013 MacPro models.

Backport from Qt 5.11

Task-number: QTBUG-70062
Change-Id: I0b0831efb6f4073ebd37672040aaed6370853fc0
Reviewed-by: default avatarAndy Shaw <andy.shaw@qt.io>
      e73bd4a5
  65. 23 Oct, 2018 - 1 commit