[Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem

noreply@sourceforge.net noreply@sourceforge.net
Wed, 08 Aug 2001 13:16:49 -0700


Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

>Category: Python Interpreter Core
Group: Not a Bug
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-08 13:16

Message:
Logged In: YES 
user_id=31435

__del__ only applies to objects coded *in* Python.  frame 
objects are coded in C, and __del__ isn't relevant to those.

Not all objects are tracked by gc, and the set of objects 
which are changes from release to release (it grows); even 
if that were documented, you'd never be able to keep it 
straight unless you were an expert too in how Python is 
implemented, and in all the implementation variations 
across releases.

Tracking an object type in gc has both memory and speed 
costs, so the pressure has been to do it only for object 
types highly likely to be involved in cycles.  Since you 
really can't get a cycle involving frame objects unless 
you're doing disgusting tricks <wink>, frame objects were 
left out of this subsystem.

In 2.2 that changes, though, because the addition of 
generators and iterators makes it more likely that a frame 
object can end up in a cycle even when you're not playing 
games with _getframe().  That is, frame objects in cycles 
will be collected by magic in 2.2 (they already are in the 
current CVS Python).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10

Message:
Logged In: YES 
user_id=6380

In Python 2.1 and 2.1.1, frames are not GC'ed.

In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).

I don't understand your question about __del__ methods.

I agree with the documentation question, but don't know
where best to add this.  I'll reopen this as a documentation
issue and assign to Fred.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470