Crash while performing foreach loop: QBasicAtomicInt::ref

[psih128]

Hi

I'm having a weird problem where my application crashes while cycling through the item in the list returned by the QObject::children() function:

MyObject::function() {
    foreach(QObject *object, children) {
       doSomethigWith(object);
    }
}

MyObject::function() {
    foreach(QObject *object, children) {
       doSomethigWith(object);
    }
}

To copy to clipboard, switch view to plain text mode 

The call stack is as follows:
#0 0x100004ad6 in QBasicAtomicInt::ref at qatomic_x86_64.h:121
#1 0x1000506a3 in QList<QObject*>::QList at qlist.h:114
#2 0x1000506dd in QForeachContainer<QList<QObject*> const>::QForeachContainer at qglobal.h:2227

In my app I have a hierarchy of QObject derived classes. Also there is a model that presents this hierarchy. This crash occurs when I assign this model to the QComboBox widget.

if I call that function MyObject::function right before the assignment, it wont crash.

Any ideas why that might be happening?

Thanks

[wysota]

Can we see a larger piece of code? Is your application multithreaded?

[psih128]

There are background threads in the application, but this particular piece of code is run in the GUI thread. Also a different instance of the same model with the same data works just fine (the second instance of the model and view are instantiated while the first one is still active).

A bit more of the call stack:

#0 0x100004c36 in QBasicAtomicInt::ref at qatomic_x86_64.h:121
#1 0x100050803 in QList<QObject*>::QList at qlist.h:114
#2 0x10005083d in QForeachContainer<QList<QObject*> const>::QForeachContainer at qglobal.h:2227
#3 0x100098961 in PersistenceObject:ersistenceChildren at persistenceobject.cpp:148
#4 0x10004242c in PersistenceObject:ersistenceChildren<Patient*> at persistenceobject.h:111
#5 0x10003d198 in Database:atients at database.cpp:106
#6 0x1000772bc in DatabaseInformationDialog::setPatient at databaseinformationdialog.cpp:283
#7 0x10017bece in DatabaseInformationDialog::qt_metacall at moc_databaseinformationdialog.cpp:82
#8 0x1015c0deb in QMetaObject::activate
#9 0x100be5910 in QComboBox::currentIndexChanged
#10 0x100be742c in QComboBoxPrivate::_q_emitCurrentIndexChanged
#11 0x100be8c1e in QComboBoxPrivate::setCurrentIndex
#12 0x100be8d81 in QComboBox::setCurrentIndex
#13 0x100beb9e6 in QComboBox::setModel

The code does not do anything except for that loop I mentioned before the crash. Here is the more complete version: it just tries to filter the QObject children:

const PersistenceObjectList PersistenceObject::persistenceChildren() const
{
        PersistenceObjectList persistenceList;
        foreach (QObject *child, children()) {
            if (PersistenceObject *persistenceChild = qobject_cast<PersistenceObject *>(child)) {
                persistenceList.append(persistenceChild);
            }
        }		
        return persistenceList;
}

const PersistenceObjectList PersistenceObject::persistenceChildren() const
{
        PersistenceObjectList persistenceList;
        foreach (QObject *child, children()) {
            if (PersistenceObject *persistenceChild = qobject_cast<PersistenceObject *>(child)) {
                persistenceList.append(persistenceChild);
            }
        }		
        return persistenceList;
}

To copy to clipboard, switch view to plain text mode 

the patients function will do some more filtering of the QObject's children based on the type (using qobject_cast)

[wysota]

What is the implementation of children()?

[psih128]

it is the QObject::children() - the base implementation.

PersistenceObject is derived from QObject

[wysota]

Are you sure the PersistenceObject instance lives in the main thread? What does thread() return for it (interprete the value, don't post the address unless it's 0x0)?

In general the only explanation of the situation I can think of is that two threads try to operate on your object at the same time causing havoc in the object's internals.

[psih128]

Ok, I finally figured this out. That was due to the crappy implementation of the PIMPL pattern - it was using uninitialized pointer.