Hi,<br><br>Am Samstag, 5. Januar 2013 schrieb  :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05.01.2013, 16:50:29 Andreas Pakulat wrote:<br>
[...]<br>
> Often a segfault is caused by using a pointer (in C++) which points to<br>
> a memory location thats not valid anymore, for example because the<br>
> object has been deleted already. In the context of PyQt this can<br>
> happen when you stop keeping references to objects that or instances<br>
> of C++-provided classes in python. In such a case the C++ parts of the<br>
> object will be deleted and thus any other C++ code that has a<br>
> reference to the object will crash when it tries to access the object.<br>
> I think thats the most common problem one encounters with PyQt4.<br>
<br>
While this is certainly true in general, I'd say that sip goes to<br>
great length in order to avoid that kind of crash by carefully<br>
observing who owns what. It is aware of the parent-child memory<br>
management of Qt. A python program should never be able to cause a<br>
crash. Is there any place in PyQt where the Python code has to keep<br>
references to keep the program going?</blockquote><div><br></div><div>Thats not always possible, it only works for objects which tell sip when they are deleted, for example QObject instances. Other Qt types do not support object life tracking like QObject, so sip has no way to know that it should not delete the object when the python reference is garbage collected.<span></span></div>
<div><br></div><div>Andreas</div>