What | Removed | Added |
---|---|---|
Status | NEW | RESOLVED |
CC | fabian@ritter-vogt.de | |
Resolution | --- | WONTFIX |
This is most likely https://bugreports.qt.io/browse/QTBUG-75605 (the referenced https://bugreports.qt.io/browse/QTBUG-75605 has a similar crash). The reason is that BasicListItem defines a contentItem itself (which is referenced through other properties), which is immediately overwritten (before the delegate is complete) by the custom delegate in qqc2-style-crash. This triggers immediate deletion of the old contentItem, but that is still being constructed at that point. When a component has an id assigned, it forces the engine to perform construction synchronously instead of deferred. With deferred construction, the contentItem is overwritten after construction is complete, and the deletion no longer affects an item during construction. This is why removing the id avoids the crash. This got fixed by https://github.com/qt/qtquickcontrols2/commit/80f1186338bcf8c7d692b4fadfc46531c002c6b0, and I can confirm that with that commit applied on top of 15.3's libqt5-qtquickcontrols2 package, the crash disappears. However, it is documented as "[ChangeLog][Important Behavior Changes]", so I don't think it should be backported at this stage. Fortunately there's a rather simple workaround (which is also recommended in the Qt documentation) which is to just omit the id. Additionally, I don't think that it makes sense to use BasicListItem and overwrite its contentItem, because there's not much of BasicListItem left and just using AbstractListItem should have the same result, but avoiding the crash.