1. 21 Mar, 2018 1 commit
  2. 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
      Task-number: QTBUG-57041
      Change-Id: I4dc5a6d25c0a32fed9fd952c955e2006c76be45a
      Reviewed-by: default avatarSimon Hausmann <simon.hausmann@qt.io>
      (cherry picked from commit aa94c6c0469b0595f483f13ac88459f0035deef9)
      (cherry picked from commit c3db3cfa296dbc5aa198520c1411830d165cd496)
    • 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: default avatarSimon Hausmann <simon.hausmann@qt.io>
      (cherry picked from commit 86702c3be53fda404ebe331207f9062675c952e0)
  3. 08 Mar, 2018 1 commit
  4. 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: default avatarMichael Brasser <michael.brasser@live.com>
      (cherry picked from commit 2659c308792967322564b5088e0e21bb371e0283)
  5. 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: default avatarMichael Brasser <michael.brasser@live.com>
      (cherry picked from commit 44a89492b49f23a975377795dbb7a48916cb5081)
      Reviewed-by: default avatarMitch Curtis <mitch.curtis@qt.io>
  6. 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: default avatarSimon Hausmann <simon.hausmann@qt.io>
  7. 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.
      Task-number: QTBUG-65828
      Change-Id: I3e57bb7a0c2dc29172a485a6ea957b6ab5ac962e
      (cherry picked from commit 16ca5eab9bdd31774dc8e657f217e044640eecff)
      Reviewed-by: default avatarLars Knoll <lars.knoll@qt.io>
  8. 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: default avatarShawn Rutledge <shawn.rutledge@qt.io>
      Reviewed-by: default avatarAndy Nichols <andy.nichols@qt.io>
      (cherry picked from commit 238cc098d785b4fe76fbc8422b340d98ff8c1a1b)
    • 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: default avatarSimon Hausmann <simon.hausmann@qt.io>
  9. 14 Feb, 2018 2 commits
  10. 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: default avatarSimon Hausmann <simon.hausmann@qt.io>
      (cherry picked from commit ff08272245c099cadd433c8b5d4f98301f5e585b)
    • 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: default avatarLars Knoll <lars.knoll@qt.io>
      (cherry picked from commit 22d43f74e264626d0c28654c42c91839f9de45b5)
      Reviewed-by: default avatarErik Verbruggen <erik.verbruggen@qt.io>
    • 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: default avatarSimon Hausmann <simon.hausmann@qt.io>
    • 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: default avatarFrederik Gladhorn <frederik.gladhorn@qt.io>
  11. 12 Feb, 2018 1 commit
  12. 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
      That change (correct as it is) introduced an accidental circular
      dependency in the simple scenario of importing a .js file in a .qml
      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: default avatarLars Knoll <lars.knoll@qt.io>
  13. 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: default avatarShawn Rutledge <shawn.rutledge@qt.io>
    • 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
      Change-Id: I4657a7b1e2b4c2977120ee8e345ee9ae7d2bbc2d
      Reviewed-by: default avatarTopi Reiniö <topi.reinio@qt.io>
  14. 07 Feb, 2018 2 commits
  15. 06 Feb, 2018 4 commits
  16. 05 Feb, 2018 3 commits
  17. 03 Feb, 2018 2 commits
  18. 02 Feb, 2018 8 commits
    • Ulf Hermann's avatar
      qmlprofiler tool: In attach mode, finish when connection drops · fb84bcb4
      Ulf Hermann authored
      We won't have a process that terminates in this case and we don't want
      to wait forever.
      Task-number: QTBUG-66159
      Change-Id: I5d0bbe2f8bc9c7cbc8732272ccca779d5f9bcc7d
      Reviewed-by: default avatarSimon Hausmann <simon.hausmann@qt.io>
    • J-P Nurmi's avatar
      Doc: add C++11 lambda examples for qmlRegisterSingletonType() · 6958308c
      J-P Nurmi authored
      Change-Id: I444137fd10041781df232447b8e2bf712582f079
      Reviewed-by: default avatarMitch Curtis <mitch.curtis@qt.io>
      Reviewed-by: default avatarShawn Rutledge <shawn.rutledge@qt.io>
    • Kari Hautamäki's avatar
      Fix transition when removing the last item from ListView/GridView · 23ea4cf5
      Kari Hautamäki authored
      Use the previous item view boundaries (before a remove was applied)
      when defining transition properties.
      Task-number: QTBUG-64311
      Change-Id: I66870a7267ac26ea430c364383f32fd5c47d4a5d
      Reviewed-by: default avatarShawn Rutledge <shawn.rutledge@qt.io>
    • Shawn Rutledge's avatar
      If Loader loads Window, set its transient parent to the Loader's window · 4b014eff
      Shawn Rutledge authored
      This makes the Item { Loader { sourceComponent: Window { } } } case
      consistent with the Item { Window { } } case: the inner Window is
      transient for the outer Window.
      It works even if the Loader's Window has a visible: true declaration:
      in that case, until now, the Loader's Window would become visible
      at component creation time, before the outer Item became visible.
      So the test to check whether it had a transient parent did not work.
      We now change the delayed-visibility mechanism in QQuickWindowQmlImpl
      to wait for the parent Item to acquire a window of its own rather
      than waiting for the transient-parent-if-any to become visible.
      It should still take care of all the old cases too, e.g. in the
      Window { Window { } } case, the inner Window's QObject parent is actually
      the QQuickRootItem.  (Amends 701255c76f671f100338a799f0194bf10e26c9d1)
      [ChangeLog][QtQuick][QQuickWindow] When a Window is declared inside
      another Item or Window, the window will not be created until
      the parent window is created.  This allows it to have the correct
      transientParent and be managed as a transient window.
      Task-number: QTBUG-52944
      Change-Id: Iaf4aafbd696f6e8dd0eec1d02db8bd181483bd07
      Reviewed-by: default avatarMorten Johan Sørvig <morten.sorvig@qt.io>
      Reviewed-by: default avatarShawn Rutledge <shawn.rutledge@qt.io>
    • Simon Hausmann's avatar
      Fix memory leak with QtQuick compiler generated files · 7bd5d938
      Simon Hausmann authored
      When for the QQC code path we do QML type re-compilation, we allocate a
      new QV4::CompiledData::Unit. We must make sure that this dynamically
      allocated memory is released in QV4::CompiledData::CompilationUnit's
      destructor, by ensuring that the StaticData flag is not set.
      This isn't directly applicable to the ahead-of-time generated cache file
      unit data as they will always be re-generated (and thus the unsetting of
      StaticData at the end of createCompilationUnit::createUnitData()), but
      I've added a test-case nevertheless to ensure the correct engine
      Change-Id: I16973d7989567892bf8bf9dd6214bf293055d260
      Reviewed-by: default avatarLars Knoll <lars.knoll@qt.io>
    • Simon Hausmann's avatar
      Fix memory leak with value types · f7ffed94
      Simon Hausmann authored
      Commit 3b14e2ff replaced the
      QQmlRefPointer<QQmlPropertyCache> with a raw QQmlPropertyCache pointer
      and added a V4_NEEDS_DESTROY tag. However unfortunately the destroy()
      method in the heap class does not decrease the reference count.
      Change-Id: I90a8c56cd638592b67aae7041fbb57c879c4146c
      Reviewed-by: default avatarLars Knoll <lars.knoll@qt.io>
    • Simon Hausmann's avatar
      Fix dead lock / race in QML type loader when importing plugins · 8c050185
      Simon Hausmann authored
      When importing modules - in the QML loader thread - with plugins we keep
      globally track of the Qt plugins that we have loaded that contain QML
      modules, to ensure that we don't call the engine-independent
      registerTypes() function on the plugin multiple times. After
      registerTypes() we may also call initializeEngine() on the plugin for
      the engine-specific initialization, which - as a QQmlEngine is provided
      as parameter - must happen in the gui thread. For that we issue a
      thread-blocking call that waits until the gui thread has woken up and
      processed the event/call.
      During that time the global plugin lock is held by that QML loader
      If meanwhile the gui thread instantiates a second QQmlEngine and
      attempts to issue a synchronous type compilation (using
      QQmlComponent::CompilationMode::PreferSynchronous), then gui thread is
      blocking and waiting for its own QML loader thread to complete the type
      compilation, which may involve processing an import that requires
      loading a plugin. Now this second QML loader thread is blocked by trying
      to acquire the global plugin registry lock
      (qmlEnginePluginsWithRegisteredTypes()->mutex) in qqmlimports.cpp.
      Now the first QML loader thread is blocked because the gui thread is not
      processing the call events for the first engine. The gui thread is
      blocked waiting for the second QML loader thread, which in turn is stuck
      trying to acquire the lock held by the first QML loader thread.
      The provided test case triggers this scenario, although through a
      slightly different way. It's not possible to wait in the gui thread for
      the plugin lock to be held in a loader thread via the registerTypes
      callback, as that also acquires the QQmlMetaType lock that will
      interfere with the test-case. However the same plugin lock issue appears
      when the first QML engine is located in a different thread altogether.
      In that case the dispatch to the engine thread /works/, but it won't be
      the gui thread but instead the secondary helper thread of the test case
      that will sit in our initializeEngine() callback.
      This bug was spotted in production customer code with backtraces
      pointing into the three locations described above: One QML loader thread
      blocking on a call to the gui thread, the gui thread blocking on a
      second QML loader thread and that one blocking on acquisition of the
      plugin lock held by the first.
      Fortunately it is not necessary to hold on to the global plugin lock
      when doing the engine specific initialization. That allows the second
      QML loader thread to complete its work and finally resume the GUI
      thread's event loop.
      Change-Id: If757b3fc9b473f42b266427e55d7a1572b937515
      Reviewed-by: default avatarUlf Hermann <ulf.hermann@qt.io>
    • Andy Shaw's avatar
      Prevent invalid characters being entered at the appropriate times · 5a10cf06
      Andy Shaw authored
      When a validator does not allow for certain characters to be entered,
      then it should not allow these to be entered in even if an input mask
      is set. This fixes a regression introduced in
      The test modified is because this is in fact a general limitation when
      combining validators and input masks, when a separator is used.
      Whereas the original patch did allow this to be possible, this is now
      not possible again.
      Task-number: QTBUG-64616
      Change-Id: Ic6a3f40a9faa7c04abc055cfc2752044fddd33a0
      Reviewed-by: default avatarFrederik Gladhorn <frederik.gladhorn@qt.io>
      Reviewed-by: default avatarRobin Burchell <robin.burchell@crimson.no>
  19. 01 Feb, 2018 1 commit