Le Sunday 26 July 2009, Thiago Macieira a écrit : > Carina Denkmann wrote: > >there seems to be a problem with this commit in qt master: > > > >http://qt.gitorious.org/+qt-developers/qt/webkit/commit/1a5e7171b9da383c > >a5f6be92b7cb6e502fd79fc4 > > > >I get a crash in QMetaObject::changeGuard() at this place: > > > > if (!more) > > QObjectPrivate::get(*ptr)->hasGuards = false; > > > >The problem could be that it accesses the object private pointer of an > > object that has already been deleted? > > > >Also, the for loop uses "it.key() == *ptr && it != end", the order of > > the checks should probably reversed. >
[...] > hasGuards is a bit in a bitfield. That means the accesses to it aren't > atomic. More than that, it means the accesses to the *other* bits in the > same bitfield aren't atomic either. > > So you probably have a race condition where one of the other bits was > changed while setting hasGuards to true. That would explain why the bit > cleared unexpectedly. > > The most likely cause is a moveToThread, but other operations like > blockSignals() can cause it too. This is not possible. According to the backtrace, the object is a QWidget, and cannot be used in different threads. What is more likely is that *ptr is a dangling pointer, meaning that the QPointer would have been created on a wrong pointer. (But then the program would have crashed before) Maybe running with valgrind might help. Carina, Do you know how to reproduce the crash? _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
