[IronPython] object lifecycle issues

[William Reade]

Damn, it's my problem -- sorry for the noise. It seems that 
IronPython.NewTypes.BlahBlah.ExtensibleBlah types don't handle equality 
quite how I expected... clearly, I need to learn to fire up windbg 
*before* I post. At least we rediscovered the __del__ bug ;-).

Incidentally, congratulations on 2.0.2!

Dino Viehland wrote:
> The first 2 things that occur to me is that either there's an exception
> happening when we run WeakRefTracker's finalizer (it swallows exceptions)
> or the object simply isn't being collected.
>
> But it definitely sounds like we're creating the object which will
> ultimately call __del__ when it gets finalized.
>
> Have you tried windbg + SOS and done a !DumpHeap to see if the object
> could still be alive?  Another thought would be to look at the finalizer
> queue and make sure it's not blocked on something (like a transition
> into an STA).
>
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Tuesday, July 21, 2009 9:20 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] object lifecycle issues
>>
>> Dino Viehland wrote:
>>     
>>> #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.
>>>
>>>       
>> In PythonOps.InitializeForFinalization, I see 2 InstanceFinalizers
>> created for each object; one after the stub __new__, and one after the
>> real __new__. Each IF creates a WeakRefTracker as expected; in both
>> cases, the second WRT (and only the second one) is subsequently
>> GC.SuppressFinalized in SetFinalizerWorker. However, in the broken
>> cases, the WRT finalizer just never gets called.
>>
>> I'll keep hunting, but it seemed worth posting this in case it rang any
>> bells.
>>
>> Cheers
>> william
>>
>>
>> _______________________________________________
>> 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
>
>