Hi, On Sat, Jan 5, 2013 at 4:09 PM, Lee Harr <miss...@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@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt