[PyQt] Help tracking down intermittent segfault using QGraphicsItem

[Erik Janssens]

Here are some things regarding detecting and preventing
segfaults I've once written down for my own reference :

http://python-camelot.s3.amazonaws.com/gpl/release/pyqt/doc/advanced/debug.html
http://python-camelot.s3.amazonaws.com/gpl/release/pyqt/doc/advanced/development.html

I have not seen an undocumented segfault caused by sip or
pyqt in the last year.

On Sat, Jan 5, 2013 at 4:50 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> Hi,
>
> On Sat, Jan 5, 2013 at 4:09 PM, Lee Harr <missive at hotmail.com> wrote:
> >> I tried pynguin-0.12.zip on Windows7, python 2.7, PyQt 4.8.4 32bit,
> >> and I could run "go()" many times without any crashes or warnings.
> >> However, there appears to be no "tournament" function.
> >
> > Thanks for taking your time on this, but the problem is only
> > in the development sources. I am doing my best to not make
> > a release that is known to segfault.
> >
> > (Dev version uses python-3.2 and pyqt-4.9)
> >
> >> One advise, if I may say so: The chance of finding someone who would
> >> be willing to debug your entire project is slim. On a mailing list
> >> such as this one, the best way is to reduce the problem to a self
> >> contained, minimum size test case which reproduces the bug.
> >
> > Yes, you are right, but I have been working on this for about a
> > month now and the only way I've been able to get it to crash
> > is in corner cases with the whole application running.
> >
> >
> > That's why I am asking for general advice on how to find and
> > squash a bug like this.
> >
> > Has anyone ever found and fixed a segfault using QGraphicsScene
> > and QGraphicsItem before? What was the problem?
> >
> > What kinds of things generally cause a segfault like this?
>
> Often a segfault is caused by using a pointer (in C++) which points to
> a memory location thats not valid anymore, for example because the
> object has been deleted already. In the context of PyQt this can
> happen when you stop keeping references to objects that or instances
> of C++-provided classes in python. In such a case the C++ parts of the
> object will be deleted and thus any other C++ code that has a
> reference to the object will crash when it tries to access the object.
> I think thats the most common problem one encounters with PyQt4.
>
> To know why the crash happens you should generate a backtrace, this is
> usually rather easy on Linux and other unix-systems by enabling
> core-dumps via something like ulimit -c 200000. Then run your program
> so it crashes, this should print out something like "core file
> generated". The file will be named 'core' and will be put in the
> current working directory of the application at the point of the
> crash. You can examine it using gdb like:
> gdb python core
> thread apply all bt full
> That generates a backtrace which you could post here, it'll probably
> hint either towards the C++ code that still has a reference to an
> already deleted object or into some sip code that thinks it can access
> an object thats actually deleted already.
>
> On Windows generating a backtrace is usually easiest done using the
> post-mortem debugger from Visual Studio, it'll show up once the app
> crashes and allows you to stop at the line.
>
> In both cases you should make sure that Qt and PyQt (and possibly sip)
> have been built with debug symbols, otherwise you won't get references
> to the functions being involved.
>
> Andreas
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20130105/43d2ffa1/attachment-0001.html>