Important: Please read the Qt Code of Conduct -

ListView with QAbstractListModel and QSortFilterProxyModel crashing on emitting dataChanged

  • I have a ListView that, when it grows so that not all the content is visible onscreen, I run into seg faults when sending dataChanged events from my model.

    I have a function that seeks to ping the QML to refresh all the content on some fairly large change, but not re-create the model, thus preserving where the user has scrolled, etc.

    To be certain of what's happening - making sure my indices are valid - I have changed my refresh code to the following:

    void MyQAbstractListModelDerived::refreshListContent()
        int lastIndex = rowCount() - 1;
        LOG(INFO) << "rowCount: " << rowCount() << " last index: " << lastIndex;
        if (lastIndex >= 0){
            for (int i = 0; i < rowCount(); i++){
                bool doesHaveIndex = hasIndex(i,0);
                if (doesHaveIndex){
                    auto beginIndex = index(i,0);
                    auto endIndex = index(i,0);
                    emit dataChanged(beginIndex,endIndex);

    In my ListView this will create a crash, for instance if I scroll to previously-off-screen list items and then invoke something that would call refreshListContent.

    However, if I add <code>cacheBuffer: 100000</code> to my ListView, the crash disappears.

    I am using roles in my model rather than invokable and the model itself doesn't directly hold the state; it's wrapping other C++ objects. My assumption is that the dataChanged signal is trying to invoke delegates that don't exist, because they are off screen, but I'm certain that this is accounted for by the Qt Framework developers. The model can't know which items are being viewed so it can't possibly know whether or not it's acceptable to send change signals for data.

    Any suggestions would be most welcome.

  • Moderators

    The delegates are recycled every-time you scroll which means there are created and destroyed as and when required internally (More here: delegate). Caching them disables it. So I guess the problem should be on the delegate side i.e the delegate is trying to access some property which it is not able and hence crashes.