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 <ap...@gmx.de> wrote: > 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 >
_______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
