[PyKDE] Confused about garbage collection and segfaults.
phil at river-bank.demon.co.uk
Tue Jun 26 22:07:52 BST 2001
"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
> >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-
The reference is maintained at the C++ level, not the Python level.
More information about the PyQt