[PyQt] sip segfault in disconnectNotify

Erik Janssens Erik.Janssens at conceptive.be
Sat Sep 18 07:49:31 BST 2010


This seems to be a QT issue indeed.  I have compiled everything
with QT 4.7 rc1 and the segfault is gone.  

It looks as if there are a lot of modifications in the QT model
view framework, where most are related to taking care of the
model being deleted, disconnecting signals when a view changes
its model etc.

On Mon, 2010-09-13 at 22:09 +0100, Phil Thompson wrote:
> On Sun, 12 Sep 2010 20:46:44 +0200, Erik Janssens
> <Erik.Janssens at conceptive.be> wrote:
> > Hello Phil,
> > 
> > Thank you for your explanation, this made things more
> > clear.  In the C++ code of qabstractitemview, the view is
> > connected to the destroy signal of the model and it looks
> > to handle a destroyed model just fine.  One way or 
> > another this falls apart in combination with a garbage
> > collector.
> 
> Hmm - I hadn't noticed that. I can only think that Qt doesn't really
> handle it properly. In older versions of PyQt a view didn't automatically
> keep a reference to the model (not the same as taking ownership). It was a
> common programmer mistake not to keep an explicit reference to the model
> resulting in a segfault. If that Qt code was working then that should never
> have happened.
>  
> > What I actually want is my model to be destroyed
> > together with its view, but if I make them both dependent
> > on the same parent object, I risk the 'random' garbage
> > collection if circular references exist.
> >
> > Therefor I tried out another technique, I register each
> > model in a global register, so it stays alive, and remove
> > it from the register when its view is destroyed.
> > 
> > This seems to work, but I'm wondering if its an appropriate
> > solution...
> 
> You may still have the problem when the interpreter is destroyed if there
> are any views still alive after exec_() returns. So you may have to
> explicitly del things.
> 
> Phil




More information about the PyQt mailing list