[PyKDE] Confused about garbage collection and segfaults.

[Phil Thompson]

"John J. Lee" wrote:
> 
> I'm confused about which segmentation faults are to be expected, and which
> would be regarded as bugs.  For example, while working through the Qt
> tutorial, I missed off a 'return' in CannonField by mistake:
> 
> class CannonField(QWidget):
> ...
>     def sizePolicy(self):
>        QSizePolicy(QSizePolicy.Expanding, QSizePolicy.Expanding)
> 
> and got a segfault.  Is this something you have to live with, or is it a
> bug?  If the former, why does it happen?

I hope that (these days) most seg faults are programmer bugs rather than
PyQt bugs. In the above example you are effectively returning None -
which will get translated as NULL and which can obviously cause
problems. I'm not saying that PyQt can't be better at detecting
programmer bugs and raising an exception.

> I don't really understand this, either:
> 
> On Wed, 04 Oct 2000 09:31:20 -0700, Phil Thompson wrote:
> > Philippe Fremy wrote:
> [...]
> > > I use the constructor
> > > QCanvasSprite( QCanvasPixmapArray * array, QCanvas * canvas).
> > >
> > > What qt does with the QCanvasPixampArray is only storing the pointer.
> > > This is ok in C++ but not in Python, because the array gets deleted at
> > > the end of my assigning function.  When I want to show the
> > > QCanvasSprite, I get a segfault.
> >
> > This is a common issue and is covered in the PyQt docs.
> 
> It is, although I couldn't find any specific mention of segfaults.
> Perhaps it's worth mentioning, as you generally aren't expecting any
> segfaults when writing in Python.

But you have to remember that you are actually writing code for a C++
library which doesn't do the same degree of run-time checks as Python
does.

> >From the PyQt docs:
> 
> > Sometimes a Qt class instance will maintain a pointer to another
> > instance and will eventually call the destructor of that second
> > instance.  The most common example is that a QObject (and any of its
> > sub-classes) keeps pointers to its children and will automatically call
> > their destructors. In these cases, the corresponding Python object will
> > also keep a reference to the corresponding child objects.
> 
> Maybe add something like "If you create a (subclass of) QObject in your
> Python code that refers to an object whose corresponding C++ object will
> remain in existence after the Python object is garbage-collected, this
> will cause a segmentation fault."?  Is that right??  Does the C++ object
> have to have a slot (implemented as a Python callable) which gets called
> from C++ at some point for a segfault to be caused?

QObjects and their children will generally "do the right thing".  A
child will stay alive while it's parent is alive. If the reference is
not using the QObject parent/child relationship then the behaviour is
defined by the particular C++ objects.  It is possible that you can end
up with a Python object that is wrapping a C++ object that no longer
exists and an attempt to dereference it will lead to a seg fault.

With a well designed C++ class library these problems are very unlikely
- Qt is well designed.

> Actually, why do you get a segfault at all in the example above?  If the
> Python instance of Python class QCanvasSprite has a reference to the
> QCanvasPixmapArray, why would the QCanvasPixmapArray get garbage-
> collected?

The reference is maintained at the C++ level, not the Python level.

Phil