On 4/26/2013 1:13 PM, Luc-Eric Rousseau wrote: > On Wed, Apr 24, 2013 at 7:34 PM, John Ehresman <[email protected]> wrote: >> Do you have a test case? Do you have a subclass of QCheckBox? The >> immediate cause is that mo in SignalManager::retriveMetaObject ends up >> being NULL, but the bug probably occurred earlier. >> >> Thanks, > I've been trying to isolate in a smaller test case and I haven't been > able to yet. > There was mention of a checkbox in that callstack, however in other > times it's elsewhere (for example as below). I do not have a subclass > of QCheckBox, it might have been the checkbox part of QT's > QListWidget if there was one. The way I'm reproducing the crash 100% > of the time is to click a push button a few times fast that changes > the selection in a QListBox, which then causes another pane to refresh > with new controls. However, if you don't do that, every once in a > while you can click another control elsewhere and *poof*, you'll crash > with the same call stack. It's just harder to reproduce an other way. > So I've come to the conclusion that there isn't anything wrong > specially with that QListWidget UI, it's just much easier to reproduce > it there.
I'm not sure how helpful this is, but I add an anecdote. I reported both https://bugreports.qt-project.org/browse/PYSIDE-160 and https://bugreports.qt-project.org/browse/PYSIDE-144 which are memory issues of some sort. Both resulted in crashes which seem similar to yours. The only way I found them was by eliminating code paths bit by bit until I found the crucial element. Both manifested most repeatedly after calls to QLayout::takeAt to replace widgets in views related to a list. I'm assuming this is because the shiboken pointer lists become corrupt and takeAt and subsequent garbage collection aggravated that corruption. Joel _______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
