-
Bug
-
Resolution: Invalid
-
P2: Important
-
6.5.9, 6.8.4, 6.9.1, 6.10.0 Beta2
-
Windows 10 22H2, MSVC 2022 x64
See the attached example. CppObj is a QML_ELEMENT while CppBridge is a QML_SINGLETON.
The example creates 2 lists, each containing 100 instances of CppObj with JavaScriptOwnership but no parents:
- IDs 0 - 99 are stored in root.customProperty (a custom list<CppObj> property)
- IDs 100 - 199 are stored in listView.model
Code
import QtQuick import QtQuick.Controls.Basic import JSOwnershipStudy ApplicationWindow id: root width: 400 height: 300 visible: true header: Button { text: "Collect Garbage" onClicked: gc() } property list<CppObj> customProperty: CppBridge.multipleObjs(0) ListView { id: listView anchors.fill: parent model: CppBridge.multipleObjs(100) delegate: Label { required property CppObj modelData text: modelData.identifier } } }
Steps to reproduce
- Run the attached example
- Click the "Collect Garbage" button
- Close the window to quit
- Repeat the test above, but scroll to the bottom of the ListView before doing Step #2
Outcomes
The CppObjs stored in customProperty (IDs 0 - 99) are never destroyed by the garbage collector but are always destroyed upon quitting.
However, for the CppObjs stored in ListView.model (IDs 100 - 199), their fate depends on whether a delegate is accessing the instance at the time when deletions are processed, and also on the Qt version:
Qt 6.5 | Qt 6.8+ | |
---|---|---|
Objects that are referenced by a delegate | Destroyed upon quitting | Destroyed upon quitting |
Objects that are not referenced by a delegate | Destroyed by the garbage collector | Never destroyed (without scrolling, probably |
In other words, even though the returned lists are the same, the list stored in root.customProperty is ref-counted properly, but the list stored in listView.model is not. The exact manifestation is version-dependent.
Setting QV4_GC_TIMELIMIT=0 and QV4_MM_AGGRESSIVE_GC=1 does not help.
- relates to
-
QTBUG-138919 [Reg 6.5.9 -> 6.8.4] Unreferenced objects with JavaScriptOwnership are no longer destroyed
-
- Closed
-
-
QTBUG-139059 Generated code does not track objects on JavaScript stack
-
- Closed
-
- resulted in
-
QTBUG-139053 Re-design transfer of QObject ownership to JavaScript
-
- Open
-
- split to
-
QTBUG-139025 [Reg 6.5.9 -> 6.8.4] Lists of objects with JavaScriptOwnership, stored in var properties, are no longer destroyed
-
- Closed
-