I'm experiencing the same fatal assertion error as described in this previous (now closed as not reproducible) bug report: https://bugreports.qt.io/browse/QTBUG-67951

It happens in QML code partly based on this example: https://github.com/KDAB/qt3d-examples/tree/master/animated-skinned-mesh,

and it behaves in the same way if the QMesh, QArmature and QSkeletonLoader are created and added to the entity from C++, instead of QML.

The original bug report has already done a good job of describing where in Qt's source code it crashes, but since it was not reproducible, I'll try to shine more light on the issue:

• I'm using a QQuickView unlike the example where a Qt3DQuickWindow is used
• It seems to a timing/race condition thing as it seems to occur in a semi-random manner, with some factors changing the risk of the assertion failure:
• It can happen with the default Mixamo Robot character in the example, but happens significantly more often with our own glTF character, possibly due to differences in the characters' size or complexity
• It's less likely to happen if the root QML Item containing the `Scene3D` is packed with additional UI, such as a `ColumnLayout` with various controls (buttons, sliders etc.) on top. Possibly increased load on UI thread during initialization helps
• It's more likely to happen with a simpler material on the character entity
• It's far more likely to happen if the character is rendered in multiple `Scene3D`s laid out in a GridView (e.g. 3x3 grid with `Scene3D` in delegate item)

• We've tried to start out by only loading the mesh (with a QMesh QML component), and then subsequently adding the Armature with SkeletonLoader in C++ after the mesh is loaded (status 2), but this doesn't seem to help.
• As described in the bug report, turning off `createJointsEnabled` in the SkeletonLoader removes the crash, but leaves us without the joints, which we need for animation purposes