[IronPython] blocker: objects deleted when they shouldn't be

Dino Viehland dinov at microsoft.com
Mon Sep 29 23:08:50 CEST 2008


It might be this week, it might be next week - I'm currently doing some perf tuning for the DLR team and am queueing up a bunch of bugs to fix in a single day or two.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Monday, September 29, 2008 10:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] blocker: objects deleted when they shouldn't be

Thanks Dino :)

Can you suggest an approximate ETA for a fix? I don't want to hassle
you, but I'm very keen to get numpy matrices working and would really
appreciate a guess -- even if it's wildly wrong, it still gives me a
framework to work within ;).

Cheers
William

Dino Viehland wrote:
> Very cool bug and great analysis - thanks for reporting this.  BTW That code lives in MetaPythonType.Calls now.
>
> It seems like this logic needs to be moved into PythonType.CreateInstance instead instead of in the generated rule code.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Monday, September 29, 2008 7:11 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] blocker: objects deleted when they shouldn't be
>
> Hi all
>
> I'm about to file this on Codeplex, but I think I've tracked down a
> subtle and nasty bug, which is blocking Ironclad with numpy (it fatally
> breaks matrices and masked arrays), and I feel compelled to shout loudly
> about it to ensure it doesn't get lost in the noise of the impending 2.0
> release.
>
> In short, the following code:
> -------------------------------------------------------------
> from System import GC
>
> class C(object):
>     _instance = None
>     def __new__(cls):
>         if C._instance is None:
>             C._instance = object.__new__(cls)
>         return C._instance
>
>     def __del__(self):
>         print 'deleting object with id', id(self)
>
> c = C()
> print 'created a C with id', id(c)
> d = C()
> print 'created another C with id', id(d)
>
> for _ in range(3):
>     GC.Collect()
>     GC.WaitForPendingFinalizers()
>
> print id(c), id(d)
> print c
> print d
> -------------------------------------------------------------
>
> ...produces the following output:
> -------------------------------------------------------------
> C:\dev\ironclad\build>ipy deltest.py
> created a C with id 43
> created another C with id 43
> deleting object with id 43
> 43 43
> <C object at 0x000000000000002B>
> <C object at 0x000000000000002B>
> -------------------------------------------------------------
>
> ...and I don't think that the 'deleting...' message should be printed at
> that point.
>
> My suspicion is that c's 'magic_finalization_wossname'* slot is being
> overwritten with a new instance after __new__ returns, leaving the
> original 'magic_finalization_wossname' unreferenced; in the fullness of
> time, that gets finalized and calls c.__del__, even though c itself
> still exists.
>
> Cheers
> William
>
> * This is probably not the actual member name, but I couldn't find the
> relevant code today, even though I remember reading it in the past...
> hopefully the implementers know what I'm trying to refer to, even if
> nobody else does.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




More information about the Ironpython-users mailing list