[IronPython] object lifecycle issues

William Reade william at resolversystems.com
Tue Jul 21 12:53:19 CEST 2009


Clearing cookies worked -- thanks guys.

http://codeplex.codeplex.com/WorkItem/View.aspx?WorkItemId=23563

Jimmy Schementi wrote:
> WRT the Codeplex issues, http://codeplex.codeplex.com is the place to post issues about codeplex itself: http://codeplex.codeplex.com/WorkItem/List.aspx. Let us know when you open a bug so we can reinforce the complaints.
>
> ~js
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
>> Sent: Monday, July 20, 2009 9:58 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] object lifecycle issues
>>
>> #1's definitely our bug.  We're caching the lookup of __init__ from Real and
>> invoking that instead of doing the lookup each time.  It should be easy
>> enough to fix.  I've opened a bug (23555 -
>> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23555)
>>
>> #2 I'd guess could be either that for some reason we're failing to detect the
>> presence of __del__ or that when we run the finalizer cleanup that we
>> believe it's part of cyclic trash and don't think we should cleanup.
>> Of those I'd think it'd be the cyclic trash detection that'd be most likely to go
>> wrong.
>>
>> I'd suggest putting a break point or some logging in
>> PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer and see
>> what's happening there.
>>
>> As for CodePlex I guess you can't even open a bug to complain to CodePlex
>> :(.  If you want to send us your browser/OS info we could open a bug for you
>> against CodePlex.  You could also try the old heavy hammer of clearing
>> cookies as maybe CodePlex has built up some bad browser state.  You could
>> also try using TeamExplorer to open the bugs but I'm not sure if you'll have
>> permissions there to do that or not.
>>
>>
>>     
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-
>>> bounces at lists.ironpython.com] On Behalf Of William Reade
>>> Sent: Monday, July 20, 2009 9:38 AM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] object lifecycle issues
>>>
>>> Hi all
>>>
>>> I have two problems that are at least somewhat related:
>>>
>>> +++ Issue 1 (probably your bug):
>>>
>>> ---------------------------------------------------------------
>>> C:\dev\ironclad - Copy>ipy y.py
>>> real new
>>> stub new
>>> real init
>>> real del
>>>
>>> C:\dev\ironclad - Copy>python y.py
>>> real new
>>> stub new
>>> stub init
>>> real del
>>> ---------------------------------------------------------------
>>>
>>> I freely admit that the attached code is pretty weird, but I really do
>>> need to do stuff like this in Ironclad. The difference in behaviour
>>> may or may not be responsible for certain failing numpy/scipy tests --
>>> I'm not sure how to tell -- but I'd enormously appreciate a fix.
>>>
>>> I'd report the issue on Codeplex, but trying to visit the issue
>>> tracker just leaves my browser spinning forever. Speaking of which: is
>>> there any alternative way of reporting bugs that doesn't make me feel
>>> as if I'm spamming the list with out-of-band noise? I'm pretty sure
>>> that a few bugs have just dropped off my stack in the last few months,
>>> just because I got tired of waiting for Codeplex to start working.
>>>
>>> +++ Issue 2 (almost certainly my bug):
>>>
>>> In a nearly identical* situation -- close enough that I can't say how
>>> it's actually different -- f will never get its __del__ method called
>>> (the object is destroyed -- a WeakReference to it knows it's dead --
>>> but the __del__ call never happens).
>>>
>>> For context: I have *very* similar classes, whose instances are
>>> constructed in exactly the weird way demonstrated in the attached
>>> file, and which work fine. The only difference between the cases that
>>> work and the cases that don't is that the broken cases multiply
>>> inherit from ipy types which wrap CLR types (int and float (and maybe
>>> str, although I haven't tested that one)), while the working cases
>>> have simple chains of single inheritance from user-defined types all the
>>>       
>> way up to object.
>>     
>>> However, the attached repro doesn't show my problem, so it's clearly
>>> not
>>> *just* to do with multiply inheriting from CLR types.
>>>
>>> Does anyone have any idea what I might be doing wrong? I know this is
>>> a vague request, but I'm running out of ideas, and I'd really
>>> appreciate some input from someone who understands precisely what all
>>> those ipy MetaFoo classes are doing.
>>>
>>> Cheers
>>> william
>>>
>>>
>>> * the attached file started life as an attempt to repro the __del__
>>> issue, and I incidentally noticed the __init__ issue.
>>>       
>> _______________________________________________
>> 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