QSortFilterProxy & QIdentityProxyModel & QAbstractItemModel = Crash :- )

JKSH

@Dariusz said in QSortFilterProxy & QIdentityProxyModel & QAbstractItemModel = Crash :- ):

mostly nope except for...

It needs to be 100% nope. Models and views are not thread-safe. They can crash if you run read/write their data from other threads.

It is possible to create thread-safe models, but you need to explicitly write your model code in a way that is thread safe.

kshegunov

What @JKSH said - no threading in the views & models.

Dariusz

So all of the issues I'm getting above could be due to running selection function on thread? :O Gotta test it now ! Brb.

kshegunov

@Dariusz said in QSortFilterProxy & QIdentityProxyModel & QAbstractItemModel = Crash :- ):

So all of the issues I'm getting above could be due to running selection function on thread?

And this is surprising? I've had a program run over a year before it hit a race condition, and I'd like to think I know what I'm doing.

Christian Ehrlicher

@Dariusz said in QSortFilterProxy & QIdentityProxyModel & QAbstractItemModel = Crash :- ):

Could the selection model cause it

It does, not could...

Dariusz

Hey

Ok so I disabled my threaded selection function but sadly I'm still getting crashes after large drag, dragging few items does not cause issue, but items with children/etc seems to cause crash more often. Its very random :- ((

Christian Ehrlicher

This still looks like a threading issue since _q_sourceRowsInserted() is the slot which is connected to the signal rowsInserted() from the source model. When both classes would be in the same thread then this function would have been called directly and not through an event like in your case here.

Dariusz

@Christian-Ehrlicher :O !

I have now
QAbstractItemModel = my model
QIdentityProxyModel = my custom identity - no changes here just place holder
QSortFilterProxyModel = this one is tweaked.

When I setModels on each of them, do I have to make any connections between them signals/slots of any of it?
I made one for selection/drag notifaction to re-select dropped items, but that is via QueuedConnection thus should not make any issue ?

I did more testing, seems like now any drag/drop is broken for me. Jezus... what a weekend.

I'm dropping QT from 5.14.0 to 5.13.1, perhaps its library bug as I'm running out of ideas whats wrong now :- (((

Christian Ehrlicher

Minimize your code until it does no longer occour so we can take a look at your model. Otherwise we can't help here anymore.

Dariusz

@Christian-Ehrlicher I wish I could but the code base is over 120k+ lines of code and its not something I can "strip away n test" in standalone module. I'm stipping all I can but so far its just a nightmare.

As far as I can tell, the drag happens "ok" but I think I fail to properly notify the identity & then sort models...

In qt docs there is the layoutChanged() function I need to handle

emit layoutAboutToBeChanged
Remember the QModelIndex that will change
Update your internal data
Call changePersistentIndex()
emit layoutChanged

which I implemented like this :

        Q_EMIT layoutAboutToBeChanged();

        QModelIndexList indexBefore;
        QModelIndexList indexAfter;
        std::reverse(newData.begin(), newData.end());

        /// Get old indexes
        for (int x = 0; x < newData.size(); ++x) {
            indexBefore.append(newData[x]->index());
        }

        if (row == -1) {
            i->appendChildren(newData);
        } else {
            i->insertChildren(newData, row);
        }
        /// get new indexes
        for (int x = 0; x < newData.size(); ++x) {
            indexAfter.append(newData[x]->index());
        }

        mim->setIcTreeNodes(newData);
        mim->setDragSucess();

        changePersistentIndexList(indexBefore, indexAfter);
        Q_EMIT layoutChanged();

But I have no idea if that is correct since I have never seen example like this before :- (

Any hints?

Dariusz

Another error I'm getting that I can't understand is this one >

######
			FATAL: ASSERT: "last < rowCount(parent)" in file itemmodels\qabstractitemmodel.cpp, line 2785
 (itemmodels\qabstractitemmodel.cpp:2785, (null))
######


######
			FATAL: ASSERT: "!this->isEmpty()" in file c:\users\qt\work\qt\qtbase\include\qtcore\../../src/corelib/tools/qstack.h, line 62
 (c:\users\qt\work\qt\qtbase\include\qtcore\../../src/corelib/tools/qstack.h:62, (null))
######

I went over entire drag/drop operation line by line checking indexes/ removeRow/insertRow routine and everything appear to be "valid" and yet I get this at the end ;[
This happens when I move last item from group in to another group, say item is index row 8
the function would be
mGenericModel->beginRemoveRows(index(), 8, 8); ? or its 8 and 8+1 ?
Else that assert is incorrect in library > Q_ASSERT(last < rowCount(parent));
Since if I'm moving last item, then last will be == rowCount(parent) which is still valid, and yet this will cause error :/ Or am I just talking total nonsense now...

Ok went line by line, error happens latter. Size of children is 9, last item index is 8, everything clears up properly. The crash happens latter in Qt ;[

It looks like its the damn persistentIndexes/proxy models not getting notified properly.

Dariusz

After getting full debug out of modelTest class I noticed an inconsistent output of row changes...
Did some digging and the issue ended up being...

AbstractModel & Identity lived in threadB
ProxySort lived in threadA.

And connection between them ended up being queuedconnection via qt auto connection system. Which meant that... the sort was getting notification incorrectly...

So lesson to learn.. "watch ur threads and what objects gets made where...".

Problem solved, for now :- )

TIA!

JKSH

Glad to hear that you're not encountering any more crashes. There's 1 last thing you should make sure of:

@Dariusz said in QSortFilterProxy & QIdentityProxyModel & QAbstractItemModel = Crash :- ):

AbstractModel & Identity lived in threadB
ProxySort lived in threadA.

All 3 models must live in the GUI thread.
All views must live in the GUI thread.

The GUI thread is the thread that creates QApplication.

Dariusz

@JKSH Yep I'm having a full run through the app now to ensure everything happens in GUI thread - that is widget/affects widget.