Important: Please read the Qt Code of Conduct -

[SOLVED] Qt 5.2 c++ model update stops working after a while

  • Hi everyone,

    I have an App, that works under Qt 5.1 (Windows), where I update a c++ model quite often, and show the result in two nested ListViews. But under Qt 5.2, after a few seconds the ListViews stop showing the changes of the model. When I slow down the update rate, it works longer, but after a while also stops working. I can't see any errors or warnings.

    Has something changed in Qt 5.2, that I should be aware of, or can this be a bug?


  • Lifetime Qt Champion


    Can you write a minimal application that reproduces this ? If so, it might be a bug/regression. You should have a look at the "bug report system": to see whether it's something known. If not you should consider opening a new report providing that minimal compilable example

  • It looks like the problem is related to the GC of the Javascript site. I pass the model to the second ListView via

    @Q_INVOKABLE JobEntryModel *getModelFor(int index);@

    and added a QDebug to the destructor of the model. After a few seconds the destructor gets called. I don't know why this works in Qt 5.1. From what I see it shoudn't work in any version.

    What is the right way to dynamically pass a model from c++ to a ListView?


  • I have found a solution. When I set
    @QQmlEngine::setObjectOwnership(model, QQmlEngine::CppOwnership);@
    @Q_INVOKABLE JobEntryModel *getModelFor(int index);@

    QML doesen't get the ownership and the GC will not destroy the model.


  • Lifetime Qt Champion

    It's still curious that the behavior changed like that. You should ask about that on the interest mailing list. You'll find Qt's developers/maintainers there (this forum is more user oriented)

  • It didn't change. The ownership semantics of QObject* values returned from Q_INVOKABLE functions has always been JavaScriptOwnership by default unless the user manually sets CppOwnership on it.

    The issue here is that v8's garbage collector doesn't run until it hits a "high watermark" level for memory usage, which means that in many applications on desktop, it never gets run. With 5.2 and v4vm, it could be that memory management is more deterministic, resulting in shorter and more regular collection cycles. This would lead to the behaviour seen above.


  • Thank you for the explanation.

    I like the new behavior of the GC, because it shows me that I have a problem in my code. So I can find it and fix it.

    Coming form only c++, I must say that the JavaScriptOwnership issue surprised me. For me it is odd, that someone else is deleting objects I created in c++.

    Thanks again.

Log in to reply