1. 05 Jun, 2018 9 commits
  2. 21 Mar, 2018 1 commit
  3. 20 Mar, 2018 2 commits
    • Erik Verbruggen's avatar
      Fix issue with bindings to aliases that cannot yet be resolved · 52b1993e
      Erik Verbruggen authored
      When an alias points to a child object which has not yet been
      initialized, it's id won't have been registered yet, so setting up a
      binding to it will result in a crash.
      
      The fix is: when setting a binding target fails, and its target property
      is an alias, queue them until all bindings have been set up, and try
      again.
      
      Task-number: QTBUG-57041
      Change-Id: I4dc5a6d25c0a32fed9fd952c955e2006c76be45a
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      (cherry picked from commit aa94c6c0469b0595f483f13ac88459f0035deef9)
      (cherry picked from commit c3db3cfa296dbc5aa198520c1411830d165cd496)
      52b1993e
    • Erik Verbruggen's avatar
      Fix JITted code for jump strict-not-equal undefined on 32bit · dc0136b8
      Erik Verbruggen authored
      The generated code for jump-on-strict-not-equal-undefined used the
      same logic (but with inverted conditions) as the equal case. For
      equality, one can jump to else if the value parts are not the same.
      So, for not-equal, if the value parts are the same, it would jump
      to the else block if they are the same. Meaning, an encoded int
      value of 0 (which is strict-not-equal to undefined) would end up
      being evaluated as equal.
      
      Task-number: QTBUG-66832
      Change-Id: I5c6b8e9b11be53ae21a7164e0a1e0cbfd204f401
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      (cherry picked from commit 86702c3be53fda404ebe331207f9062675c952e0)
      dc0136b8
  4. 08 Mar, 2018 1 commit
  5. 26 Feb, 2018 1 commit
    • Simon Hausmann's avatar
      Allow setting values in value type group properties in "on" assignments · ded165b9
      Simon Hausmann authored
      Assigning to a group property inside a property value source or
      interceptor as part of an "on assignment" is perfectly valid. That is
      because while "color" is a value type property, the on assignment means
      we're actually setting easing.type (in the example and test) on the
      property value source, not the color, and that one is a QObject. The
      same goes for interceptors.
      
      Change-Id: I505a658977a578894d6dfb00bf5c65b41e42b12f
      Task-number: QTBUG-56600
      Reviewed-by: 's avatarMichael Brasser <michael.brasser@live.com>
      (cherry picked from commit 2659c308792967322564b5088e0e21bb371e0283)
      ded165b9
  6. 23 Feb, 2018 1 commit
    • Simon Hausmann's avatar
      Fix ListModel.get(idx) == ListModel.get(idx) · ec4c897d
      Simon Hausmann authored
      This is a regression introduced with commit
      4876ea6a. Where we previously always
      returned the same JS object, we would afterwards return a new JS object
      for every invocation, which breaks reference comparison. As we store the
      JS wrapper for the list element in the QQmlData->jsWrapper we can avoid
      repeated allocations. In order for that wrapper to keep working after
      modifications (insertion, etc.) to the list model, we have to replace
      the static element index with a reference to the node model meta-object,
      which also has an element index that however is kept up-to-date by the
      list model itself.
      
      Change-Id: I4368de6b6d86687fe96fbf73bd60b80b69d7b058
      Task-number: QTBUG-52017
      Reviewed-by: 's avatarMichael Brasser <michael.brasser@live.com>
      (cherry picked from commit 44a89492b49f23a975377795dbb7a48916cb5081)
      Reviewed-by: 's avatarMitch Curtis <mitch.curtis@qt.io>
      ec4c897d
  7. 22 Feb, 2018 1 commit
    • Erik Verbruggen's avatar
      Remove superfluous assert when traversing IR · b6d1e97b
      Erik Verbruggen authored
      When accessing/calling a property on an object, it is possible (and
      perfectly fine) for that object to be a constant value. I.e. Undefined.
      All code handling such a call do handle constants correctly.
      
      Note: this is a 5.9 specific change, because 5.11 got rid of this code.
      
      Task-number: QTBUG-66027
      Change-Id: Ied9d0c9c8f8bf958f8634f7be196900b3ea64861
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      b6d1e97b
  8. 16 Feb, 2018 1 commit
    • Lars Knoll's avatar
      Fix crash when changing from a simple to a sparse array · 8fdf4667
      Lars Knoll authored
      After that change, if we ran out of slots in the freeList,
      the last entry would point to the first Value in the value
      array, not indicating that we ran out of free slots.
      
       Conflicts:
      	src/qml/jsruntime/qv4sparsearray_p.h
      
      Task-number: QTBUG-65828
      Change-Id: I3e57bb7a0c2dc29172a485a6ea957b6ab5ac962e
      (cherry picked from commit 16ca5eab9bdd31774dc8e657f217e044640eecff)
      Reviewed-by: 's avatarLars Knoll <lars.knoll@qt.io>
      8fdf4667
  9. 15 Feb, 2018 2 commits
    • Simon Hausmann's avatar
      Fix crash with the software renderer and windows with QObject parent · 557e7629
      Simon Hausmann authored
      When a QQuickWindow is a child of another QObject (such as a Loader) and
      is scheduled for deletion using a deferred delete event, then a deletion
      via the parent ends up calling the window's destructor, which will
      finally end up in ~QObject(), which takes care of removing the posted
      deferred deletion event from the event queue.
      
      In the case of QQuickWindow, the destructor - called before ~QObject -
      calls windowDestroyed(this) on the SG render loop. The implementation in
      the software renderer calls QCoreApplication::sendPostedEvents() with
      QEvent::DeferedDelete, which ends up deleting the same window a second
      time and resulting in a crash.
      
      I can't see a good reason for the existence of the sendPostedEvents()
      call there. It is not present in the other render loops and according to
      git blame it stems from the very early first implementation of the
      software renderer where surely copy & paste from other render loop code
      was involved back then.
      
      The same fix is applied to the single-threaded VG and D3D12 render
      loops, as they are most likely copy & paste from the software render
      loop implementation.
      
      ASAN trace for tst_qquickwindow::unloadSubWindow() on 5.11 branch that shows
      invalid access to the QObjectPrivate/QQuickWindowPrivate, which follows the
      QObject in terms of life-cycle:
      
      ==4736==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000011778 at pc 0x7fdd211cfbb3 bp 0x7fffecb47ea0 sp 0x7fffecb47e90
      READ of size 8 at 0x617000011778 thread T0
          #0 0x7fdd211cfbb2 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1308
          #1 0x7fdd21470974 in QQuickWindowQmlImpl::~QQuickWindowQmlImpl() items/qquickwindowmodule_p.h:63
          #2 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103
          #3 0x7fdd21470974 in QQmlPrivate::QQmlElement<QQuickWindowQmlImpl>::~QQmlElement() .../qqmlprivate.h:103
          #4 0x7fdd1e24da24 in qDeleteInEventHandler(QObject*) kernel/qobject.cpp:4601
          #5 0x7fdd1e253d2f in QObject::event(QEvent*) kernel/qobject.cpp:1240
          #6 0x7fdd1fbd1d41 in QWindow::event(QEvent*) kernel/qwindow.cpp:2356
          #7 0x7fdd211f778e in QQuickWindow::event(QEvent*) items/qquickwindow.cpp:1628
          #8 0x7fdd1e1a4e3c in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) kernel/qcoreapplication.cpp:1216
          #9 0x7fdd1e1a508b in doNotify kernel/qcoreapplication.cpp:1157
          #10 0x7fdd1e1a555a in QCoreApplication::notify(QObject*, QEvent*) kernel/qcoreapplication.cpp:1143
          #11 0x7fdd1fb87665 in QGuiApplication::notify(QObject*, QEvent*) kernel/qguiapplication.cpp:1723
          #12 0x7fdd1e1a52fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) kernel/qcoreapplication.cpp:1067
          #13 0x7fdd1e1b6ed2 in QCoreApplication::sendEvent(QObject*, QEvent*) ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
          #14 0x7fdd1e1b6ed2 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) kernel/qcoreapplication.cpp:1764
          #15 0x7fdd1e1b8cda in QCoreApplication::sendPostedEvents(QObject*, int) kernel/qcoreapplication.cpp:1618
          #16 0x7fdd210cb034 in QSGSoftwareRenderLoop::windowDestroyed(QQuickWindow*) scenegraph/adaptations/software/qsgsoftwarerenderloop.cpp:100
          #17 0x7fdd211cfb8c in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1305
      [...]
      
      0x617000011778 is located 632 bytes inside of 704-byte region [0x617000011500,0x6170000117c0)
      freed by thread T0 here:
          #0 0x7fdd21a8a9d8 in operator delete(void*, unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe19d8)
          #1 0x7fdd2146fa3c in QQuickWindowQmlImplPrivate::~QQuickWindowQmlImplPrivate() items/qquickwindowmodule.cpp:57
          #2 0x7fdd1e26b252 in QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*) [...]
          #3 0x7fdd1e26b252 in QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer() [...]
          #4 0x7fdd1e26b252 in QObject::~QObject() kernel/qobject.cpp:882
          #5 0x7fdd1fbcf51c in QWindow::~QWindow() kernel/qwindow.cpp:211
          #6 0x7fdd211d0466 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1297
          #7 0x7fdd211d0644 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1335
          #8 0x7fdd1e2666b4 in QObjectPrivate::deleteChildren() kernel/qobject.cpp:1995
          #9 0x7fdd1e26b329 in QObject::~QObject() kernel/qobject.cpp:1023
      [...]
      
      Change-Id: Iffa90d365d02b074e2a78c5be2895c9f86a4b80e
      Task-number: QTBUG-66381
      Reviewed-by: 's avatarShawn Rutledge <shawn.rutledge@qt.io>
      Reviewed-by: 's avatarAndy Nichols <andy.nichols@qt.io>
      (cherry picked from commit 238cc098d785b4fe76fbc8422b340d98ff8c1a1b)
      557e7629
    • Erik Verbruggen's avatar
      Correctly set this object when calling scope/context functions · b2420780
      Erik Verbruggen authored
      When a function is called that is in a QML scope or a QML context, set
      the 'this' object to the QML scope.
      
      Note: this patch is 5.9 specific. 5.11 has a similair issue, but the
      implementation is quite different, so that needs a separate fix.
      
      Task-number: QTBUG-59357
      Change-Id: Ia78e012d413c40a094e957f4020502cd055ac286
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      b2420780
  10. 14 Feb, 2018 2 commits
  11. 13 Feb, 2018 4 commits
    • BogDan Vatra's avatar
      Use only cache path to cache .qmlc files on Android · 8342f0b9
      BogDan Vatra authored
      Task-number: QTBUG-58223
      Change-Id: Ibc599ac2e62aa60405af0022c7f5bab6eac3e3c4
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      (cherry picked from commit ff08272245c099cadd433c8b5d4f98301f5e585b)
      8342f0b9
    • Simon Hausmann's avatar
      Fix memory leak with ListModel.get · fc333db8
      Simon Hausmann authored
      This is a regression introduced with commit
      3cc589c9, which in turn fixed a leak
      with QV4::QObjectWrapper objects. Unfortunately the allocate() call into
      the persistent (weak) value storage in the list model introduced a leak
      of the weak value itself. This is fixed by replacing the free standing
      weak value allocation with the use of the existing jsWrapper weak value
      in the declarative data (QQmlData). That weak value is freed property in
      the destroy() method of the QV4::QObjectWRapper. The extra QQmlData
      allocation is hidden behind a unified allocation, similar to what we do
      in void QQmlType::create(QObject **, void **, size_t) const.
      
      Task-number: QTBUG-66189
      Change-Id: I5351e3e484542709a6b210e84aa19b14d28e11ad
      Reviewed-by: 's avatarLars Knoll <lars.knoll@qt.io>
      (cherry picked from commit 22d43f74e264626d0c28654c42c91839f9de45b5)
      Reviewed-by: 's avatarErik Verbruggen <erik.verbruggen@qt.io>
      fc333db8
    • Erik Verbruggen's avatar
      Prevent huge arrays to overflow the JS stack during GC · efc7f855
      Erik Verbruggen authored
      The JS stack is used as a worklist while marking in order to prevent
      recursion overflowing the C stack. Now if all contents of an array are
      pushed onto the stack, it can easily cause an overflow. To prevent this,
      drain the stack periodically.
      
      This is fix that should not go into 5.11, as it's already fixed there by
      using a ValueArray that will have this exact behavior.
      
      Change-Id: Id5bd28879f6ef0265344d9a70c25f6c66b067309
      Task-number: QTBUG-62087
      Reviewed-by: 's avatarSimon Hausmann <simon.hausmann@qt.io>
      efc7f855
    • Aleix Pol's avatar
      QQuickItemView::currentItemChanged called upon currentItem destruction · 0e64bd96
      Aleix Pol authored
      There were some cases where the signal wasn't emitted and we ended up
      with events being delivered to objects that didn't exist anymore.
      
      Task-number: QTBUG-65881
      Change-Id: I847669a978e82a0332907b029a8295bb993d2850
      Reviewed-by: 's avatarFrederik Gladhorn <frederik.gladhorn@qt.io>
      0e64bd96
  12. 12 Feb, 2018 1 commit
  13. 09 Feb, 2018 1 commit
    • Simon Hausmann's avatar
      Fix memory leak with JS imports · d4ff2907
      Simon Hausmann authored
      Strictly speaking this is a regression introduced with commit
      e22b624d, making the QQmlContextData
      objects reference counted, especially from the V4 QML context wrapper
      objects.
      
      That change (correct as it is) introduced an accidental circular
      dependency in the simple scenario of importing a .js file in a .qml
      file:
      
      Each time the type in the .qml file is instantiated, we create a
      dedicated QQmlContextData for the .js file. If the .js file has no
      imports itself, that new context will get the same ctx->importedScripts
      JS array as the QML context of the .qml file. That is a strong reference
      via QV4::PersistentValue. That array in turn contains the
      QV4::QmlContextWrapper that belongs to the imported script, which in
      turn holds a strong reference (via refcount) to the script's context.
      
      This patch breaks the circular reference when we perform context
      invalidation, as the least intrusive measure.
      
      For the auto-test to work, we must also clear the qmlContext persistent
      of the QV4::Script that's used to evaluate the .js file. In subsequent
      imports that persistent will be initialized to new values, so it will
      only hold a strong reference to the last import, but strictly speaking
      that is still a leak - hence also part of this fix.
      
      Change-Id: I3e543c946e5e683425072dc3df7e49ca0e0c0215
      Task-number: QTBUG-66189
      Reviewed-by: 's avatarLars Knoll <lars.knoll@qt.io>
      d4ff2907
  14. 08 Feb, 2018 2 commits
    • Mitch Curtis's avatar
      tst_qquickflickable: fix compiler warning · 94afe0db
      Mitch Curtis authored
      tst_qquickflickable.cpp:822:47: warning: ignoring return value of ‘bool
       QTest::qWaitForWindowActive(QWindow*, int)’, declared with attribute
      warn_unused_result [-Wunused-result]
      
      Change-Id: I39be58a1032e36f650ce2e008026faaf368cca3f
      Reviewed-by: 's avatarShawn Rutledge <shawn.rutledge@qt.io>
      94afe0db
    • Mitch Curtis's avatar
      Document how to work with arrays using QJSValue · 601ef224
      Mitch Curtis authored
      - Mention (in the detailed description) that Array is indeed supported.
      - Provide examples for getting and setting individual array elements,
        and how to read the length of the array.
      - Properly document the property() and setProperty() overloads that
        take an index.
      - Link to the overloads where it makes sense.
      
      These changes make the intended workflow for using arrays much more
      obvious.
      
      Change-Id: I4657a7b1e2b4c2977120ee8e345ee9ae7d2bbc2d
      Reviewed-by: 's avatarTopi Reiniö <topi.reinio@qt.io>
      601ef224
  15. 07 Feb, 2018 2 commits
  16. 06 Feb, 2018 4 commits
  17. 05 Feb, 2018 3 commits
  18. 03 Feb, 2018 2 commits