SIGSEGV error during memory deallocation in QQuickItem destructor

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