On my Debian testing desktop I noticed a crash when browsing in
systemsettings to the lock screen configuration and trying to go
back or closing the application.
Please see attached file at the end for backtrace of the crash.
After "some time" looking into it I believe that the crash occours
because of the following events:
- ScreenLockerKcmForm constructor calls QQmlContext::setContextProperty
(configDialog). That way a pointer to ScreenLockerKcmForm get stored as
some Qml/QV4 objects (QObjectWrapper).
- ScreenLockerKcmForm destructor is called.
- The inherited QWidget destructor is called.
- The QObjectPrivate member declarativeData is set to 0 (qwidget.cpp:1679)
- QObjectPrivate::deleteChildren is called.
- The QObjectPrivate member currentChildBeingDeleted is set to the next one
to be deleted. (qobject.cpp:1968)
Unfortunately is declarativeData and currentChildBeingDeleted sharing
the same memory - therefore declarativeData is now not 0 anymore.
- One of the childs tries to clean up the Qml/QV4 magic.
- Now in QObjectWrapper::destroyObject a QQmlData pointer is retrieved.
That way the QObject pointer currentChildBeingDeleted is now retrieved via
declarativeData as a QQmlData pointer.
Can someone at least reproduce the crash?
Is there something I should include in another debugging session?
I think this also is somehow related to the crash filed in bug #361236.
At least it ends in the same QV4::Value::as member (qv4value_p.h:351).
The minimal testcase creates a main window with a single QQuickWidget.
Via setContextProperty the pointer to the MainWindow instance is stored.
If at Qml side a property of this instance is accessed we get this
crash in the destructor.
(An exmple gdb run on my machine is included.)