[PyKDE] Double free() problem in PyQt 3.15.1??

[Phil Thompson]

On Saturday 22 April 2006 4:04 pm, Simon Edwards wrote:
> Hello,
>
> I've spent some more time playing with this problem some more. (See
> attachment). I've added some dumpObjectTree() calls and debug for the
> __del__ methods for the two dialogs. To me it clears looks like SIP and
> Python disagree about who is responsible for destroying the popup dialog.
> The __del__ method for the popup is called two times.
>
> I'm confused as to what the newer exec_loop() code in QDialog was meant to
> do.
>
> ---------------------------------
> %If (Qt_3_0_0 -)
> 	int exec() /PyName=exec_loop, ReleaseGIL,
> 		    PreHook=__pyQtPreEventLoopHook__,
> 		    PostHook=__pyQtPostEventLoopHook__/;
> %MethodCode
> 		// Transfer ownership back to Python (a modal dialog will
> 		// probably have the main window as it's parent).  This means
> 		// the Qt dialog will be deleted when the Python wrapper is
> 		// garbage collected.  Although this is a little inconsistent,
> 		// it saves having to code it explicitly to avoid the memory
> 		// leak.
> 		sipTransferBack(sipSelf);
>
> 		Py_BEGIN_ALLOW_THREADS
> 		sipRes = sipCpp->QDialog::exec();
> 		Py_END_ALLOW_THREADS
> %End
> %End
> -----------------------------------
>
> It looks like it is meant to take ownership away from the parent dialog and
> let Python handle destruction of the popup. But the dumpObjectTree() lines
> in my test code say that the parent dialog always keeps the popup on it's
> list of children objects.

Correct.

> When the parent dialog is destroyed so are the children objects. This is a
> problem if Python thinks that it should destroy the popup too.

It's not a problem because QObject's dtor does the right thing in taking 
itself out of any parent's list of children. In other words, it doesn't 
matter (in the case of QObject and its subclasses) if both Python and C++ 
think they should call the dtor.

> I can't explain why Phil's Qt only examples does not fail like the KDE
> version. :-/
>
> It is possible to work around this problem by explicitly calling
> QDialog.removeChild() to remove the popup from the parent dialog's list of
> children.

The whole point was to avoid extra coding like this - which a lot of people 
wouldn't realise was necessary.

Phil