On Thu, 08 Mar 2012 23:14:49 +0100, Jonathan Kleinehellefort
wrote:
> On Thu, 08 Mar 2012 10:03:46 +, Phil Thompson
> wrote:
>> Even if there is a reference cycle the garbage collector should break
it
>> if it is being allowed to run. Any test should explicitly invoke it.
>
> Not sure if thi
On Thu, 08 Mar 2012 10:03:46 +, Phil Thompson
wrote:
> Even if there is a reference cycle the garbage collector should break it
> if it is being allowed to run. Any test should explicitly invoke it.
Not sure if this applies here, but I think the Python GC will not call
destructors on objects
On Wed, 07 Mar 2012 20:09:36 +0100, Jonathan Kleinehellefort
wrote:
> Thanks, I tried it. Now, instead of being destroyed early, the object
> is never destroyed, which I believe means that it leaks memory. Maybe
> you created a reference cycle?
Even if there is a reference cycle the garbage col
Thanks, I tried it. Now, instead of being destroyed early, the object
is never destroyed, which I believe means that it leaks memory. Maybe
you created a reference cycle?
-- Jonathan
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.rive
On Fri, 24 Feb 2012 17:13:11 +0100, Jonathan Kleinehellefort
wrote:
> Hallo,
>
> I was asked to debug memory corruption problem in some sip-based Python
> bindings, and what I found leads me to believe that sip is to blame.
> I'll try to explain the problem:
>
> Let's say you have a C++ class th
Hallo,
I was asked to debug memory corruption problem in some sip-based Python
bindings, and what I found leads me to believe that sip is to blame.
I'll try to explain the problem:
Let's say you have a C++ class that looks like this:
struct C { M m; };
And then let's assume there is some Py
