[IronPython] object lifecycle issues

Jimmy Schementi Jimmy.Schementi at microsoft.com
Tue Jul 21 00:28:33 CEST 2009


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




More information about the Ironpython-users mailing list