Starting/stopping timers from another thread may result in errors that
may not appear until hours, days or weeks after if a release build of
Qt is used with the GLib/UNIX event dispatchers. Such errors may
manifest as warnings such as "QObject::killTimer(): Error: timer id 7
is not valid for object 0x2a51b488 (), timer has not been killed" and
application crashes (e.g. crashes in malloc, realloc and
malloc_consolidate).
Initial-patch-by: Eike Ziller <eike.ziller@digia.com>
Task-number: QTBUG-40636
Change-Id: I2de50d50eb1fc7467fcebb9c73b74d2f85137933
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For some reason it seems to be supported to call moveToThread(0).
That call will allocate a new QThreadData for the object. However,
if we then detect that we're calling moveToThread from a thread
which is not the one the QObject has affinity with,
we error out leaking that QThreadData object.
Change-Id: I0fe6625a2a9887535e457f3897b514d2a03d1480
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
When no objectName is set, this will give at least some information,
other than the memory address of the current instance.
Change-Id: Iae452c0e9fe38f0aab35094ddf0edc0fd6b28c20
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Manually included changes from
3a347a4e70e5a10ee92dd2578316c926a399e894
in src/opengl/qgl.cpp.
Conflicts:
src/opengl/qgl_qpa.cpp
src/plugins/platforms/android/androidjnimain.cpp
Change-Id: Ic26b58ee587d4884c9d0fba45c5a94b5a45ee929
Fix disconnection from pointer to member signal that belongs to the base
class, but whose type is a pointer to a member of the derived class.
Commit 9cc106d9d7d951fcf30f4b0f8606afa6b50892ec fixed connect, so apply
the same fix in disconnect
[ChangeLog][QtCore][QObject] Fixed disconnecting from pointer to member
signal that belongs in the base class but whose type is explicitly given
as a pointer to a member in the derived class
Task-number: QTBUG-40638
Change-Id: Ia546fc8f36e1ea0dd0645bdd820aea47f43677ac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QObjectPrivate::Connection::method should never be called when
the Connection was made with the function pointer syntax
This caused valgrind warning about using uninitialized value on such code:
QObject::connect(&o, &Object::aSignal, &o, &Object::aSlot);
o.disconnect(&o, SLOT(aSlot()));
Change-Id: Iaff9ecd3ddfe665db92726b420021493453c4cea
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QMetaType::create can call user code and we should not keep mutex held as
this may cause dead lock.
Make sure the tst_qobjectrace actually emit some signal so the test check
there is no race if the receiver object is destroyed while
the mutex is unlocked.
Task-number: QTBUG-39990
Change-Id: I56ca1ae7a11cd7b33c1a68727370972862e11c2f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
mkspecs/qnx-x86-qcc/qplatformdefs.h
src/corelib/global/qglobal.h
src/network/socket/qnativesocketengine_winrt.cpp
src/plugins/platforms/android/androidjniaccessibility.cpp
src/plugins/platforms/windows/qwindowswindow.cpp
Manually adjusted:
mkspecs/qnx-armle-v7-qcc/qplatformdefs.h
to include 9ce697f2d54be6d94381c72af28dda79cbc027d4
Thanks goes to Sergio for the qnx mkspecs adjustments.
Change-Id: I53b1fd6bc5bc884e5ee2c2b84975f58171a1cb8e
When a new-style connection is created (a SlotObject), we don't store
the method offset since there isn't one. So don't try to read it.
Qt::UniqueConnection only applies to old-style connections, since we
can't compare the slot objects for equality. In any case, an old-style
connection and a new style will never be considered equal.
Task-number: QTBUG-39927
Change-Id: I10a39a7bc97a2ec9509a0708038cc491bcc67329
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Elias Probst <mail@eliasprobst.eu>
QSignalBlocker resets to the previous state, which might have already
been a blocked signal state.
Task-number: QTBUG-39352
Change-Id: I918cc6ea346755b940e027cee5d6704824fbba32
Reviewed-by: David Faure <david.faure@kdab.com>
These hooks only worked reliably with LD_PRELOAD on Linux/GCC, on other
platforms they depended on what exactly the compiler optimizer is doing
as well as some nasty assembler rewriting to actually access them. The
new system uses a simple array of function pointers that can be set to
custom hooks by tools that need this (based on ideas from Andre Poenitz).
This also covers qt_startup_hook (similar problem), and the Qt version
number that Andre had asked for.
Change-Id: I2c3e7950fd49b1b1d04176be34c2fff3293981b0
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Correct links and fix typos, remove obsolete documentation,
fix some snippets, mark some classes as internal.
Change-Id: I9a3266605f060783413d32740057a57a820c8929
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
The slot object was deleted after the mutex was relocked, which caused
a deadlock in case the functor destructor locked the same mutex again.
Change-Id: I5b4fb22fdb4483f91c89915872bfd548c31b0eea
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
This fixes QtQuick key handling not propagating key events beyond the
specific onXPressed handlers, due to erroneously thinking those exist,
when signal spy callbacks are present.
Considering signal spies for isSignalConnected() goes back to 87239ef6 in
Qt4, and seems to be there just due to this code being based on activate(),
where this check obviously makes sense.
Change-Id: Iad41e42a8d3ee2a16a55be7d1a7cdc51484981ce
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
When building with debug, all SLOT or SIGNAL macros will
expand to a function call, and then function will call
QThreadData::current(), which will set
QCoreApplication::theMainThread if it has not already been
done. Since Qt Widgets has these macros in the static
initialization of the library, we would register the
Android main thread as the main thread of Qt, which would
mean that the actual application object was created on
a different thread than the main thread. This caused warnings
to appear, and also triggered a race condition which
caused widget applications to sometimes show a black screen
instead of content on startup when run with the OpenGL plugin.
Task-number: QTBUG-35048
Change-Id: Ie8979f5e7cd5662f8d7dd276de9f94f27cc120b5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QObject::senderSignalIndex is, combined with ::sender(), the current
hotspot in the QWebChannel which makes heavy use of it in its 1-to-many
QSignalSpy implementation.
This patch optimizes the senderSignalIndex by only iterating over the
linked senders list once, instead of twice. I.e. it first iterated over
it to find the signal index, then again to find the sender to convert
to a method-offset.
Change-Id: Ic86aed0dce891b87b953a6ec2364a81695bd4876
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
According to docs DynamicPropertyChange event should be sent from
setProperty function only when property is added, removed or
changed.
Change-Id: I080a27a4119a63580b03172f4b5b367338c6f440
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
When QSignalBlocker was reviewed, move semantics were asked for.
This patch add them.
This makes QSignalBlocker usable as a by-value argument (to transfer
control of signal blocking into a function) as well as as a return
value (to transfer control of signal blocking out of a function).
Change-Id: I714aa2a283bb33dba76e860649e88ed202e913c5
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Instead of enforcing the check, we'll simply trust developers to do the
right thing. For one, it's useful to mix libraries during testing
(regression testing, git bisects, etc.). For another, Qt developers are
faced day-to-day with binary incompatibility issues anyway, so this
check is mostly superfluous.
If there's one commit we could be sure that isn't breaking binary
compatibility, that's the "Bump Qt version" commit. And yet that's the
one that would cause the fatal to trip...
Change-Id: I8965f764a6ca1b2d125b42bce7ac6b27e3afc8ac
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Unfortunately the QObject destroyed callbacks for QtQml and QtDeclarative can't
be called in sequence, because if the QQmlData has the ownsMemory bit set, then
the destroyed callback will delete the QQmlData, and the sub-sequent call to
the destroyed callback of qml1 will try to dereference the QQmlData's first bit
(ownedByQml1), which is already destroyed.
This patch fixes that by simply sharing the assumption of the first bit
indicating module ownership (QtQml vs. QtDeclarative) also to qtbase and using
it to distinguish between which destroyed callback function to call.
Task-number: QTCREATORBUG-10273
Change-Id: I2773a31a3e9b3a1c22d1c1f33b2f29f3296cb3cf
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
And that connectNotify and disconnectNotify might be called from
another thread
Task-number: QTBUG-34829
Change-Id: Id118b97b92e9aa085a1d4368282294f90cfb1706
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
As the last line in the QObject destructor, we call setParentHelper(0) to
remove ourselves from the parent. In the process of that we also initiate the
QML parentChanged callback. The first thing that parentChanged callback used to
do (but now does it too late, after 26350b5ceafa0ade1328037f6234a7d288eb8f48 in
qtdeclarative) is to check if the object was deleted and then return. We could
re-introduce the check there, but I think it's cleaner to not bother calling
the callback on a dead object in the first place.
Change-Id: Ia4d43b65a9b3744a451b4c312a2d6f9c0e3b67dc
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
The regression was introduced in 5885b8f775998c30d53f40b7f368c5f6364e6df4
QMetaObjectPrivate::disconnectHelper may unlock the sender mutex. And
while relocking it, we need to make sure to lock the sender and receiver
mutex in the right order. So don't lock the receiver mutex in advance, but
re-lock it for each connection.
Change-Id: I4f6d19791cdcce3693d7f45e7beb6b564fd69277
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
When we unlock the mutex, we need to take in account that the Connection
pointed by 'node' may be destroyed in another thread while it is unlocked
Doing 'node->prev = &node' will make sure that 'node' is actually
updated when it is destroyed.
Setting isSlotObject under the mutex is safer and ensure that no other
thread will attempt to deref the object.
The regression was introduced in 5885b8f775998c30d53f40b7f368c5f6364e6df4
tst_qobjectrace was updated to catch races arising when we are
connecting with function pointers.
Change-Id: Ia0d11ae8df563dad97eb86993a786b579b28cd03
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Qml has a bunch of hooks in QObject, that are callbacks as function pointers
when things happen in QObject. QtDeclarative (Qml1) only needs one callback,
for object destruction. In preparation for allowing both run-times to co-exist,
this patch forks the callback, keeping the "default" variant for QtQml and
having a *_qml1 variant for QtDeclarative. QtQml continues to set the callback
variable for the default and QtDeclarative will set the _qml1 variant.
It is however a limitation that a QObject instance can only be exposed to _one_
engine at a time, and it is not possible to make a transfer. Double exposure
will result in crashes.
This patch alone is not sufficient to fix the bug, the
QQmlData/QDeclarativeData structures in Qml1 and Qml2 need to be extended to
allow distinction at run-time.
Task-number: QTBUG-35006
Change-Id: I3bac023873b5656a8a4f117fe816bafcda77b67d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
If the two QObjecs are connected and destroyed at the same time, it
is possible to hit a case where QObject::metaObject and QObject::disconnectNotify
is called on a destroyed object.
This patch moves the calls up before the removal of the connection. This
ensure the sender object will have to block on the receivers connection
mutex and can not finish destruction before disconnectNotify is called.
Task-number: QTBUG-34131
Change-Id: I398116fe7bc6a195991aff9961d89a8b0ac8d53c
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
I don't think I ever worked on a project of non-trivial
size that didn't at some point add a QSignalBlocker.
This commit adds code, tests and documentation. Later
commits will convert naked blockSignals() calls to use
QSignalBlocker.
The implementation is purely inline to avoid the heavy
overhead of cross-dll function calls for this miniscule
task. This should not be a problem because QSignalBlocker
only uses public API and a pattern that we anyway need
to keep working until Qt 6, at least, so even changing
the implementation later will be no problem as the old
implementation lurking in non-recompiled code will be
acceptable, too.
This implementation is an evolution from KDTools'
KDSignalBlocker, with the following changes:
- Implements unblock() and reblock()
- Uses the return value of blockSignals() instead of a
separate signalsBlocked() call.
Change-Id: I1933dfd72a0f5190324be377cfca3c54cf3d6828
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Default values should have mark-up to denote that they are code.
This commit changes:
-"property is true" to "property is \c true".
-"Returns true" to "Returns \c true".
-"property is false" to "property is \c false".
-"returns true" to "returns \c true".
-"returns false" to "returns \c false".
src/3rdparty and non-documentation instances were ignored.
Task-number: QTBUG-33360
Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
- Create a section dedicated to this concept, which is fundamental to
signal/event handling
- Move relevant content from the very broad "Thread Basics" page to the
QObject class ref
- Flesh out existing content, including distinguishing signals from
events
- Address the common misconception that "member" = "child"; this has
been encountered several times in the Qt Project forums
Change-Id: I5e7e6c848596e72c0bb623f8442c8389b81ad9ef
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
