Possible memory corruption in 5.6.1 and 5.7 RC

dbrunner

Hi all,

We've run into a problem when building our app with Qt newer than 5.6.0 (tried 5.6.1 and 5.7 RC). It throws errors while loading, usually "Cannot assign object to property" referencing a QML line that should not produce that error. The errors occur on both Windows (MinGW) and Linux. It doesn't appear to involve a bug in the C++ parts of our project. I can make the crash appear and disappear by commenting or uncommenting pieces of QML code such that the same set of C++ classes is used. When I run it using Memcheck, Helgrind, and DRD on Linux, the only errors that come up are in Qt code (mostly to do with registering types with QML or making signal connections).

Unfortunately, I haven't been able to reduce it to a simple test case, since I haven't found a pattern in what can be instantiated in QML to cause the error. For example, I tried removing all but one tab from my main window's TabView. Now, simply adding a second tab (empty but for an empty GridLayout) causes the failure.

I'm at a loss as to where to proceed next, except for bisecting the Qt source itself (which could get quite time-consuming due to the long build time). Does anyone have any ideas on what could be going on, or knowledge of the internals of QML/V4 that sheds some light on this?

In case it's helpful, our source is on Bitbucket; it can be downloaded with

hg clone ssh://hg@bitbucket.org/xcptools/xcpsetup

The project page is at https://bitbucket.org/xcptools/xcpsetup/. The only external dependency is Boost 1.60 (other versions will probably work too; only the headers are needed). The subproject causing the most grief is hgmutils/hgmparam. I've created a branch (ST-124) with portions of the QML commented out to allow the program to run. Uncommenting things (e.g. the KeypadDisplayLayout tab in ParamTabView.qml) will break it.

Thanks!
--Doug

DavidFaure

Seeing the same error with the plasma clock applet. I don't think "memory corruption" is the right term btw (actually I ran valgrind and it says no problem). This is more of a race condition (not necessarily in the multithreading sense, but at least in the "order of async operations is undefined, leading to varying behaviour between runs).

When StackViewDelegate.qml gets loaded after StackView.qml, everything's fine.
If it's loaded before (as it happens in some runs, for some unknown reason), then this happens (the debug output was added by me) :

QQmlTypeLoader::getType: QUrl("file:///d/qt/5/kde/qtbase/qml/QtQuick/Controls/StackViewDelegate.qml") calling load
QQmlPropertyCacheCreator::createMetaObject: this=0x7f07cd31b1b0 REGISTERING objectIndex= 0 as "StackViewDelegate_QMLTYPE_148"
QQmlTypeLoader::getType: QUrl("file:///d/qt/5/kde/qtbase/qml/QtQuick/Controls/StackView.qml") calling load
QQmlTypeLoader::getType: QUrl("file:///d/qt/5/kde/qtbase/qml/QtQuick/Controls/StackViewDelegate.qml") calling load
QQmlPropertyCacheCreator::createMetaObject: this=0x7f07cd31a330 REGISTERING objectIndex= 0 as "StackViewDelegate_QMLTYPE_150"
[....]
QQmlPropertyValidator::validateObjectBinding: "Cannot assign object to property. StackViewDelegate_QMLTYPE_148 does not inherit from StackViewDelegate_QMLTYPE_150"
QQmlPropertyValidator::validateObjectBinding: StackViewDelegate_QMLTYPE_148 inherits QObject

i.e. StackViewDelegate is registered twice, under two different "dynamic class names", and when the assignment happens, the property validator says the two types are incompatible.

jpnurmi

This issue has been fortunately fixed in the upcoming final release of Qt 5.7.0, coming out any day now. It's not yet clear whether there will be a special 5.6.1-1 release, or if 5.6.2 will be released already. In any case, it certainly will be fixed in 5.6.x as well, as soon as possible.

jpnurmi

@jpnurmi said:

It's not yet clear whether there will be a special 5.6.1-1 release,

5.6.1-1 is being prepared and will be made available as soon as the packages are ready: http://lists.qt-project.org/pipermail/releasing/2016-June/004284.html

DavidFaure

Excellent! Thanks very much for the information. Phew, that was a nasty one.