Segfaults Everywhere
Dear Lazyweb,
A few weeks ago rng started to show some segfaulty behavior. I’ve absolutely no idea what’s going on, since Python code usually doesn’t segfault. I guess the problem lies in the qt3-bindings rng uses — does someone know how to verify this?
There is a backtrace which seems to show that the problem lies somewhere in /usr/lib/python2.5/site-packages/qt.so but I’m not entirely sure how to interpret that.
Tags: lazyweb, reportbug-ng
July 8th, 2008 at 12:55 am
Obvious one first… RAM? memcheck86?
July 8th, 2008 at 6:41 am
Qt3 python bindings unfortunately segfault quite happily. Been there, got really upset about them.
The problem I had with them was, that Qt will delete objects when their parent is deleted. Python may however still have references to them and will go boom when it attempts to touch them. You have to be extremely careful when you keep pointers to widgets and other stuff inside dialogs and also in destructors (you generally need to use the Qt finalize instead, because the destructor will run after the underlying object is deleted).
This is a combination of binding-unfriendly Qt behaviour (Qt can’t really be made to cooperate with a garbage-collector) and sloppines on the python Qt bindings (which should use the finalization signal to invalidate the proxy, but does not do it).
July 8th, 2008 at 6:46 am
I should add, that there is a script for gdb, that will print a python backtrace given a core-dump of a crashed python interpreter. I don’t recall where I found it, but it should be googleable. You can use it to find whether it’s accessing object after being deleted and which object it could be.
July 8th, 2008 at 1:48 pm
I think that Jan Hudec suggest to use this script:
http://svn.python.org/view/python/trunk/Misc/gdbinit?view=auto
But these macros are old, and some of them will not work if they are run with a recent python interpreter.