SIGSEGV error during memory deallocation in QQuickItem destructor

FrenchMac

We are running into problems using QtQuick 2.0 on Qt 5.0.1 and 5.0.2. Our program have been ported from Qt4/QtQuick 1.1 and was running without problems since one year and a half.

We are using QML in conjunction with C++. The program manages a Playlist of contents. Each of them are described in QML. The program dynamically creates some QQuickItem from C++ and adds them to the QML elements tree. They are correctly displayed. When a content is no more needed to be displayed, it is removed (the C++ program then calls the deleteLater() method on the QQuickItem).

In the event loop, Qt destroys the QQuickItem. But from times to times (after 2 or 3 minutes of execution), the program crashes on the QQuickItem destructor. It seems that something goes wrong with elements properties deallocation in the Qt code.

We track this problem during one week and find that the more deleteLater() we execute the soon the program crashes.

Is there something else to do when doing a deleteLater() (we already try to do a setParent(NULL) and even a setParentItem(NULL) before but without success).

Thanks in advance.

Roger

Here is a stack trace when the problem occures (the crash is in the Thread #1):

Thread 1 (Thread 0xb4aa3700 (LWP 2071)):
#0 0xb640bf70 in ?? () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5V8.so.5
No symbol table info available.
#1 0xb638b73e in v8::V8::DisposeGlobal(v8::internal::Object**) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5V8.so.5
No symbol table info available.
#2 0xb7aa7cb9 in QQmlVMEMetaObject::~QQmlVMEMetaObject() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Qml.so.5
No symbol table info available.
#3 0xb7aa8062 in QQmlVMEMetaObject::~QQmlVMEMetaObject() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Qml.so.5
No symbol table info available.
#4 0xb7a874e3 in ?? () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Qml.so.5
No symbol table info available.
#5 0xb6c865c1 in QObjectPrivate::~QObjectPrivate() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#6 0xb7da5a9c in QQuickItemPrivate::~QQuickItemPrivate() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Quick.so.5
No symbol table info available.
#7 0xb7da5ad2 in QQuickItemPrivate::~QQuickItemPrivate() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Quick.so.5
No symbol table info available.
#8 0xb6c8bc7b in QObject::~QObject() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#9 0xb7da8861 in QQuickItem::~QQuickItem() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Quick.so.5
No symbol table info available.
#10 0x0808844a in WidgetItem::~WidgetItem (this=0x8c35270, __in_chrg=<optimized out>) at ../NeoPlayer/widgetitem.cpp:10
No locals.
#11 0x080683fd in QQmlPrivate::QQmlElement<WidgetItem>::~QQmlElement (this=0x8c35270, __in_chrg=<optimized out>) at /opt/Qt5.0.2/5.0.2/gcc/include/QtQml/qqmlprivate.h:91
No locals.
#12 0x0806845b in QQmlPrivate::QQmlElement<WidgetItem>::~QQmlElement (this=0x8c35270, __in_chrg=<optimized out>) at /opt/Qt5.0.2/5.0.2/gcc/include/QtQml/qqmlprivate.h:91
No locals.
#13 0xb6c85043 in qDeleteInEventHandler(QObject*) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#14 0xb6c86d28 in QObject::event(QEvent*) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#15 0xb7d9d689 in QQuickItem::event(QEvent*) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Quick.so.5
No symbol table info available.
#16 0xb74f6f84 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Widgets.so.5
No symbol table info available.
#17 0xb74fa994 in QApplication::notify(QObject*, QEvent*) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Widgets.so.5
No symbol table info available.
#18 0xb6c5cafe in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#19 0xb6c5ecc4 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#20 0xb6c5f21c in QCoreApplication::sendPostedEvents(QObject*, int) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#21 0xb6ca9f14 in ?? () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#22 0xb61b7d86 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#23 0xb61b8125 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#24 0xb61b8201 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#25 0xb6caa328 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#26 0xb4840bb6 in ?? () from /opt/Qt5.0.2/5.0.2/gcc/plugins/platforms/libqxcb.so
No symbol table info available.
#27 0xb6c5b336 in QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#28 0xb6c5b774 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#29 0xb6c5f2c2 in QCoreApplication::exec() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Core.so.5
No symbol table info available.
#30 0xb6f12334 in QGuiApplication::exec() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Gui.so.5
No symbol table info available.
#31 0xb74f2124 in QApplication::exec() () from /opt/Qt5.0.2/5.0.2/gcc/lib/libQt5Widgets.so.5
No symbol table info available.
#32 0x080583e3 in main (argc=2, argv=0xbffff684) at ../NeoPlayer/main.cpp:315

chrisadams

Please file a bug in the bug tracker, and include this information, plus a (preferably simple!) example which demonstrates the problem.

It looks like the v8object associated with the QObject-derived-type instance is invalid at the time that it tries to free it. This suggests either that your code is scribbling some memory and invalidating that handle accidentally (ie, bug in your code), or that we're not tracking handles correctly in the VMEMO code and freeing something that we shouldn't or when it's not safe to do so (ie, bug in our code).

From just this backtrace, I'm not sure which, but it's entirely possible that it's a bug in the VMEMO code to be honest.

Cheers,
Chris.

/edit: when you run it under valgrind does it tell you anything more?

FrenchMac

Thank you for this reply.

We don't share QObject with the QML code but our QML code makes use of XmlListModel and from time to time affect http urls to the source property of image elements.

We will try to reproduce the problem with a simple project source.

I will try the valgrind tool to see if it gives us more informations.

Best Regards,

Roger

Leonard777

Did you end up filing a bug report? We are seeing the same issue and we'd like to see the status of it. If not, then we can file one.

FrenchMac

No, we still don't have found the time to simplify the C++ part of our program to create a test case (we have simplify the qml part).
The problem remains in 5.1 and prevent from dynamically creating a lot of qml animations). We are using Qt in the digital signage area so we must ensure that programs works for minutes if not hours without crashing.

Thank you for the interest in our problem.

Leonard777

What compiler are you using for you development?
Visual Studio or MinGW?

We are seeing this error when we compile with Visual Studio, but not when we use MinGW.

FrenchMac

We are using MinGW. But it doesn't seems related to the compiler but more to the communication between QQuickItem and the underlying JS engine.

If we replace the item->deleteLater() with:

QTimer::singleShot(5000, this, SLOT(postponedDestroyItem()));

...

void ClassName::postponedDestroyItem() {
item->deleteLater();
}

We encounter far fewer crashes. But still it crashs after one or two hour of continuous execution.

Leonard777

We were able to resolve the issue on our end. It was a missing /MD compiler flag for the msvc compiler.
I have not seen this behavior in MinGW so what we're seeing may be different.

FrenchMac

We have continued investigating this problems for month now (it is really blocking for allowing us to use Qt 5.0/Qt 5.1) and what we found is that the problem occured when there is a deleteLater() (in C++) on a dynamically created QML element that contains running animations. Either when the animation modify a property for an object that is been destroyed or when the destructor of this object is called, a segmentation violation occured. We implement a stop() JavaScript method on all our dynamically created element to stop all the running animations. But still there seems to be no way to stop running QML Behavior.
Does anyone ever encounter such a problem?

It does make QML totally unstable for application such as digital signage (where it could be a really cool solution).

Kieren

Hi,
has this bin ever solved?

I'm using Qt5.4 on VS2013 and it appears that my program is running in exactly the described issue with deleteLater.

The code I use creates dynamic QML items which are stored as QQuickItem. As soon as they are not needed any longer they are scheduled to be destroyed using deleteLater().
Also as previously described in this thread setParent(nullptr) setParentItems(nullptr) doesn't make any difference.

In my code this only happens if the QML has bindings to C++-External classes, which are definitively still alive and in well shape at the point the QuickItem gets destroyed.

I know thread necromancy is not always a good think. So if it helps anybody I'll create a new thread.

Thanks for your help
Cheers
Kieren

Kieren