[PyQt] Help tracking down intermittent segfault using QGraphicsItem

[Andreas Pakulat]

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