qt/qtdeclarative.git, branch v5.12.9 Qt Declarative (Quick 2) Avoid duplicate call to destroy 2020-06-09T04:25:28+00:00 Fabian Kosmale fabian.kosmale@qt.io 2020-06-08T09:52:21+00:00 722caf22ad321166a6a212c74e96b5e7730c2553 Fixing the lifetime issue in emitDestruction led to a new issue: Setting linkedContext to nullptr before refCount has been incremented and invalidate has run can lead to calling destroy twice on the same pointer, and as a result to a use-after-free crash. Amends 0c8e51705ac0bb86c4b123ecd30a11b41fd50b24 Task-number: QTBUG-84095 Change-Id: Ib2ce76a45977217d0fb0f0e3ce06b24858b90468 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit a84537a159e9d3b9b66a9a0d4fdf3b1b9d3168d6) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
Fixing the lifetime issue in emitDestruction led to a new issue: Setting
linkedContext to nullptr before refCount has been incremented and
invalidate has run can lead to calling destroy twice on the same
pointer, and as a result to a use-after-free crash.

Amends 0c8e51705ac0bb86c4b123ecd30a11b41fd50b24

Task-number: QTBUG-84095
Change-Id: Ib2ce76a45977217d0fb0f0e3ce06b24858b90468
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit a84537a159e9d3b9b66a9a0d4fdf3b1b9d3168d6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Add changes file for Qt 5.12.9 2020-06-09T04:24:46+00:00 Antti Kokko antti.kokko@qt.io 2020-06-03T10:51:21+00:00 f23314a639dc628661c21115b74f5be07a890845 Change-Id: I49cf28dfc9be5511f16d4675f56c3759867e4981 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> 
Change-Id: I49cf28dfc9be5511f16d4675f56c3759867e4981
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Prevent premature child destruction 2020-06-05T11:08:03+00:00 Fabian Kosmale fabian.kosmale@qt.io 2020-06-03T14:32:35+00:00 73a1b230642dd3577563cf8a5ff95223e6b9bd4e QQmlContextData::emitDestruction suffers from the fact that code can delete objects while emitDestruction is ongoing. Notably, the sequence child->emitDestruction can trigger a call to a->destruction (of one of child's attached components), which then can indirectly delete both child and child->nextChild (for instance, when a StackView gets cleared). We prevent this by using QQmlContextDataRef when iterating over the children, which keeps the child alive for the duration of the loop. Fixes: QTBUG-84095 Change-Id: I03a4e817904ba2735e1ffc15d509db95a1a4729e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit 0c8e51705ac0bb86c4b123ecd30a11b41fd50b24) 
QQmlContextData::emitDestruction suffers from the fact that code can
delete objects while emitDestruction is ongoing. Notably, the sequence
child->emitDestruction can trigger a call to a->destruction (of one of
child's attached components), which then can indirectly delete both
child and child->nextChild (for instance, when a StackView gets
cleared).
We prevent this by using QQmlContextDataRef when iterating over the
children, which keeps the child alive for the duration of the loop.

Fixes: QTBUG-84095
Change-Id: I03a4e817904ba2735e1ffc15d509db95a1a4729e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit 0c8e51705ac0bb86c4b123ecd30a11b41fd50b24)
qquickitemgrabresult: Check effective window for visibility 2020-06-02T11:54:35+00:00 Kai Uwe Broulik kde@privat.broulik.de 2020-04-23T06:53:38+00:00 0a9fb6ce3a0c04a01081f576776290cfa0cb8e29 When using QQuickWidget, the quick scene is in an offscreen window which isn't visible, so grabToImage would always abort with "item's window is not visible". Checking the render window for the item fixes that. Task-number: QTBUG-55879 Change-Id: I58153e02e78623ba4ea6e7beec18a7503de7feeb Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit 7c9a54907f44b7e30ceac1975edcfa7920ffafd8) 
When using QQuickWidget, the quick scene is in an offscreen window which isn't visible,
so grabToImage would always abort with "item's window is not visible".
Checking the render window for the item fixes that.

Task-number: QTBUG-55879
Change-Id: I58153e02e78623ba4ea6e7beec18a7503de7feeb
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 7c9a54907f44b7e30ceac1975edcfa7920ffafd8)
Rephrase Chunk::sortIntoBins() for more clarity 2020-06-02T08:52:40+00:00 Ulf Hermann ulf.hermann@qt.io 2020-05-20T15:23:13+00:00 b4d4c4773d95b8b770b359594966162339c1bd7f Assigning -1 to a quintptr so that it later overflows in another place when adding 1 warrants a comment. Also, assert against i overflowing the bitmaps. This way coverity might also understand what we are doing. Coverity-Id: 175402 Change-Id: I212110cbb784f89b1865bd0c0cc775c08cd40c04 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 1c928f65ab9c7a495f84943ba1264acb4dbca0b8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
Assigning -1 to a quintptr so that it later overflows in another place
when adding 1 warrants a comment. Also, assert against i overflowing the
bitmaps.

This way coverity might also understand what we are doing.

Coverity-Id: 175402
Change-Id: I212110cbb784f89b1865bd0c0cc775c08cd40c04
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 1c928f65ab9c7a495f84943ba1264acb4dbca0b8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Prettify QV4_SHOW_BYTECODE output for JS classes 2020-06-02T08:15:24+00:00 Ulf Hermann ulf.hermann@qt.io 2020-05-20T14:37:00+00:00 9bd647885138cf15b4578f3f7311110bf6f36282 Drop all the double spaces, force a line break after each class, and avoid converting empty strings to utf8. Coverity-Id: 190711 Change-Id: I789291e257aeac97c2a931bfc604f453c39906eb Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 512fde525ea5972bbae2796d6b2054fd370a5275) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
Drop all the double spaces, force a line break after each class, and
avoid converting empty strings to utf8.

Coverity-Id: 190711
Change-Id: I789291e257aeac97c2a931bfc604f453c39906eb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 512fde525ea5972bbae2796d6b2054fd370a5275)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Don't return a pointer to a local in QObjectWrapper::getQmlProperty() 2020-06-02T08:14:23+00:00 Ulf Hermann ulf.hermann@qt.io 2020-05-20T13:54:14+00:00 208c98b7e97690179cb16b132a4bf26baa79e0d7 findProperty() can optionally create the property on the fly. We store the result on the stack. In that case we can figure out that the property exists, but we cannot return its value. This is OK, as we do the same in the default case below. Coverity-Id: 193545 Change-Id: I3a87fc6f577807e2daf74eeacd2aab61f40aefc8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 7645c8e0f88a83d021f0a327617189b7772b14eb) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> 
findProperty() can optionally create the property on the fly. We store
the result on the stack. In that case we can figure out that the
property exists, but we cannot return its value. This is OK, as we do
the same in the default case below.

Coverity-Id: 193545
Change-Id: I3a87fc6f577807e2daf74eeacd2aab61f40aefc8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 7645c8e0f88a83d021f0a327617189b7772b14eb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Improve polish loop detection and diagnostics 2020-05-26T09:35:37+00:00 Jan Arve Sæther jan-arve.saether@qt.io 2020-05-07T00:55:33+00:00 abaa8cf657111c86f1db72dff65a0c85e158f7b1 The existing warning was pretty much useless since it would only warn after having looped INT_MAX times. In addition, it didn't actually detect if polish() was called from within updatePolish(). Instead, the counting is changed to be strictly more correct: The counter is now only increased when polish() is called within the updatePolish(). It will reset back to 1 if that does not occur. Effectively, the counter will reflect how many consecutive polish loops we have processed. This patch will show diagnostics after having reached 1000 consecutive polish loops. It will only warn for the next 5 items in order to not be too verbose...(most likely they will be the same 5 items). If the counter reaches 100,000, we break out of the loop: This might be important for e.g. CI runs so that the process can actually terminate in order to get some useful diagnostics. Note that the item that calls polish() within updatePolish() doesn't have to be the same item as updatePolish() was called on. We also want to track these since there might be several items working in tandem to create the loop. With this change it will now give the following output: main.qml:10:5: QML Row: possible QQuickItem::polish() loop main.qml:10:5: QML Row: Row called polish() inside updatePolish() of Row (This is when Row called polish() from within its own updatePolish()) Fixes: QTBUG-40220 Task-number: QTBUG-83856 Change-Id: Ib8a7242908082c70d8cf71efbbe1fa148dbfada0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 1c8bce285522e0dcfd13fe6c514f4756d6d6438c) Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 
The existing warning was pretty much useless since it would only warn
after having looped INT_MAX times. In addition, it didn't actually
detect if polish() was called from within updatePolish().

Instead, the counting is changed to be strictly more correct:

The counter is now only increased when polish() is called within the
updatePolish(). It will reset back to 1 if that does not occur.
Effectively, the counter will reflect how many consecutive polish loops
we have processed.

This patch will show diagnostics after having reached 1000 consecutive
polish loops. It will only warn for the next 5 items in order to not be
too verbose...(most likely they will be the same 5 items).

If the counter reaches 100,000, we break out of the loop:
This might be important for e.g. CI runs so that the process can actually
terminate in order to get some useful diagnostics.

Note that the item that calls polish() within updatePolish() doesn't
have to be the same item as updatePolish() was called on. We also want
to track these since there might be several items working in tandem to
create the loop.

With this change it will now give the following output:

  main.qml:10:5: QML Row: possible QQuickItem::polish() loop
  main.qml:10:5: QML Row: Row called polish() inside updatePolish() of Row

(This is when Row called polish() from within its own updatePolish())

Fixes: QTBUG-40220
Task-number: QTBUG-83856
Change-Id: Ib8a7242908082c70d8cf71efbbe1fa148dbfada0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 1c8bce285522e0dcfd13fe6c514f4756d6d6438c)
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Fix handling of QQuickViewPrivate::root 2020-05-25T08:21:38+00:00 Ulf Hermann ulf.hermann@qt.io 2020-05-20T12:37:12+00:00 5654d77ef667438ea13ed219e39d39080f769d66 QQuickView is supposed to own the root item and shall also track it for external deletion. Therefore, when we assign a new root item we need to delete the old one. There is no point in setting a QPointer to nullptr after deleting it. It will do that by itself. When we fail to assign a new item, we should _not_ automatically delete the new one. Calling code typically does not expect the argument to a set* call to be deleted right away. Rather, return a boolean indicating whether we have successfully set the root object. This can then be used to get rid of the object if necessary. Coverity-Id: 218729 Change-Id: I79ed37d22d304bcc6d4e3c956b83a65fe157dfe0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit a64ee3a2481499f856d0f3fbc697399e0df1e8f8) Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 
QQuickView is supposed to own the root item and shall also track it for
external deletion. Therefore, when we assign a new root item we need to
delete the old one. There is no point in setting a QPointer to nullptr
after deleting it. It will do that by itself. When we fail to assign a
new item, we should _not_ automatically delete the new one. Calling code
typically does not expect the argument to a set* call to be deleted
right away. Rather, return a boolean indicating whether we have
successfully set the root object. This can then be used to get rid of
the object if necessary.

Coverity-Id: 218729
Change-Id: I79ed37d22d304bcc6d4e3c956b83a65fe157dfe0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit a64ee3a2481499f856d0f3fbc697399e0df1e8f8)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Fix failing assertion in the GC with JIT 2020-05-22T13:30:54+00:00 Simon Hausmann simon.hausmann@qt.io 2020-04-27T07:06:44+00:00 ba047960a1af56249bd5f64883aaa70bddf48313 Commit d4edf441257b7e5782a6c25802d821647ffcba45 fixed the issue for architectures where the return value register overlaps with the accumulator register and thus clobbers it (x86-64, x86). The issue however persisted on ARMv7 (and in theory also ARMv8). Further investigation suggests that another source of clobbering of the accumulator register may be the caller of the JIT generated code itself, since we never explicitly initialize the register. So if one of the first byte code instructions is the creation of a call context or ConvertThisToObject - anything that saves the register to the JS stack frame - then we could end up with the GC trying to mark a value that contains garbage (or looks like a managed, typically). Change-Id: I719e189c3314c85adb23fb2ab2a0acf26a418d4e Task-number: QTBUG-83384 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit d12c2716064e1dc6013c175952a34146a69aa507) 
Commit d4edf441257b7e5782a6c25802d821647ffcba45 fixed the issue for
architectures where the return value register overlaps with the
accumulator register and thus clobbers it (x86-64, x86). The issue
however persisted on ARMv7 (and in theory also ARMv8). Further
investigation suggests that another source of clobbering of the
accumulator register may be the caller of the JIT generated code itself,
since we never explicitly initialize the register. So if one of the
first byte code instructions is the creation of a call context or
ConvertThisToObject - anything that saves the register to the JS stack
frame - then we could end up with the GC trying to mark a value that
contains garbage (or looks like a managed, typically).

Change-Id: I719e189c3314c85adb23fb2ab2a0acf26a418d4e
Task-number: QTBUG-83384
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit d12c2716064e1dc6013c175952a34146a69aa507)