QTableWidget Crash in Destructor

[mclark]

What prevents Qt from sorting during inserts (please read the full message before answering)?

Does the following sound plausible?

1. A user presses a QTableWidget column header to initiate a sort of 215 rows of 6 cells each (1290 items).
2. I receive a notification to add a row and disable sorting BEFORE Qt has finished the previous sort.

If Qt is not done sorting when I disable sorting and start adding row items, could the item pointers become confused and account for the problems outlined above?

[wysota]

Can (2) happen from within the sort() method of the proxy or the base model? Remember that sorting is synchronous, so unless you provided your own implementation of sort(), the answer will be "no". If you are using multiple threads, then you shouldn't be accessing the same QObject from more than one thread.

[mclark]

This one appears unsolvable so I'll just have to change my design. I'll collect all notifications in the main app. When the dialog is constructed, the table will only contain a snapshot of devices known at the time of dialog instantiation.

The table in the dialog will not be updated dynamically. Not a big deal but the original problem still irritates...

Thanks to all who tried to help!

[wysota]

But do you use more than one thread in your application?

[mclark]

But do you use more than one thread in your application?

Yes, multiple threads are running in the app. In the offending dialog, a notification thread was running. The notification handler was locked using a QMutexLocker, where the mutex was declared as a class member. This should protect the table insertion code, no?

QMutexLocker locker( &m_NotifyMutex );

QMutexLocker locker( &m_NotifyMutex );

To copy to clipboard, switch view to plain text mode 

[wysota]

You can't access QObjects from more than one thread and no mutex will help here. You have to make sure that you follow that rule.