ComboBox on a page in a StackView causes an assert failure in AddConnection

  • I've been having an issue where using a ComboBox (Controls 2) in an item rendered on a StackView is causing switching to new views on that StackView to throw an assertion error in QObjectPrivate::addConnection. I'm running Qt 5.9.1 on Windows 10 amd64 using the MinGW 5.9.1 32bit compiler. I'm using Qt Creator 4.9.2 as my IDE.

    I've recreated the problem in the Qt Quick Application - Stack project template by adding a ComboBox to the Page1Form.ui.qml.

    import QtQuick 2.9
    import QtQuick.Controls 2.2
    Page {
        width: 600
        height: 400
        title: qsTr("Page 1")
        Label {
            text: qsTr("You are on Page 1.")
            anchors.centerIn: parent
        ComboBox {
            id: comboBox
            model: ["123", "456", "1435", "5347", "56798", "5789", "7-0", "87509", "3564", "543", "3425", "64532", "763", "8746",
             "75364", "847", "085", "456", "4678", "7864", "542", "736", "478", "354", "4321", "6425", "735", "53678", "54678", "5879",
             "4536", "451", "736", "847", "5497", "245", "375", "9785", "069", "8567", "6524", "5243", "4256", "34576", "2346",
             "2546", "54687", "7689", "5679", "9865", "56789", "9867", "45679", "2346", "73", "5678", "5", "27", "46785", "874"]
            x: 28
            y: 37

    I get the error when I scroll through the drop down list on the combo box and choose something and then go to switch pages on the StackView. It doesn't happen all of the time, but it happens most of the time.

    It's worth noting that I can get this error to show up much more reliably when I 'm running with the QT Debugger attached. I think this is because there is some kind of race condition at the root cause of this issue.

    The program dies at the assert on kernel\qobject.cpp:385

        Q_ASSERT(c->sender == q_ptr);

    At this point the this pointer is 0x16c, which is obviously causing a segmentation fault. Other times I've seen the data being compared in the assertion be 0xfeeefeee, so it was obviously memory that had been cleared by HeapFree.

    The stack trace shows that this problem is ultimately caused from a notify from a QEvent::MetaCall event. This leads to a QQmlEngineDebugServiceImpl::processMessage call, followed by 11 frames of QQmlEngineDebugServiceImpl::buildObjectList, eventually leading to the addConnection call for the corrupted memory address. At this point, I've reached the limit of my diagnostic skills. Could anyone give me any clues as to what I'm doing wrong or some other data I could try to look up to debug this issue?

    Attached is a backtrace of the offending UI thread, but the site is popping up a permissions error when I try to upload it so I don't know if it will actually be available to anyone.
    [0_1563368797747_Backtrace.txt](Uploading 100%)

    Thank you for taking the time to look at this.

  • Update: I downloaded the most recent version of Qt, 5.13.0, and I could not get the issue to repeat. So I think the problem is related to specific versions of Qt.