And just the __init__ bug is bad enough that it makes it all worth it! :)
> -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of William Reade > Sent: Wednesday, July 22, 2009 4:52 AM > To: Discussion of IronPython > Subject: Re: [IronPython] object lifecycle issues > > 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-boun...@lists.ironpython.com [mailto:users- > >> boun...@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@lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > > _______________________________________________ > > Users mailing list > > Users@lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
