You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Local variables not freed when Exception raises in function called from cycle #49891
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2009-04-02.14:17:22.728>created_at=<Date2009-04-01.08:49:37.495>labels= ['interpreter-core', 'performance']
title='Local variables not freed when Exception raises in function called from cycle'updated_at=<Date2009-06-17.09:40:30.245>user='https://bugs.python.org/Glin'
Situation:
You have a while cycle. inside of it a try-except block and in this
try-except block calling a function. Inside of this function raises an
exception, with is caught in the try-except block.
What happens:
Local variables of the function are not freed. (OK, they are freed when
the program leaves a function inside of which is the while cycle, or
when another exception raises and is caught, but it's not helpful when
you have some server program based on infinite while loop or working
with a large amount of data).
Example:
Example program is attached.
Output of the example program:
While start
job() start
Creating 1
Catched AttributeError
While end
While start
job() start
Creating 2
job() end
Deleting 2
While end
While start
job() start
Creating 3
job() end
Deleting 3
While end
...
As you can see, a variable 'a' created in the first call (which throws
an exception) of the 'job' function will never get freed.
Imagine that in 'job' function you create a large amount of data, or
worse you create a database connection, which will be opened forever.
Tested on Python 2.5.2 and 2.7(svn). On the contrary, Python 3.0 does
not have this issue (it frees variables of the 'job' function at the end
of except: block.)
As Python 2.X will be another long time with us, I think it should be
fixed to behave correctly (that is as in Python 3.)
This is not a question of "correct" behavior, but of documented
semantics. We can't change that semantics in 2.x, like we did for 3.x,
because many people rely on the exception variable being available after
the except clause finishes.
I just spend several days figuring out a problem that was caused by this
behaviour and in the process I really tried to read everything that
relates to destruction of objects and exception handling in Python.
Georg, could you give me a pointer where exactly these semantics are
documented?
Well, it's the basic principle that an object is not destroyed until
there are no more references to it. The documented semantics I referred
to are that a variable assigned to in an "except X, Y" clause lives
beyond the scope of that clause.
Activity
Glin commentedon Apr 1, 2009
Situation:
You have a while cycle. inside of it a try-except block and in this
try-except block calling a function. Inside of this function raises an
exception, with is caught in the try-except block.
What happens:
Local variables of the function are not freed. (OK, they are freed when
the program leaves a function inside of which is the while cycle, or
when another exception raises and is caught, but it's not helpful when
you have some server program based on infinite while loop or working
with a large amount of data).
Example:
Example program is attached.
Output of the example program:
While start
job() start
Creating 1
Catched AttributeError
While end
While start
job() start
Creating 2
job() end
Deleting 2
While end
While start
job() start
Creating 3
job() end
Deleting 3
While end
...
As you can see, a variable 'a' created in the first call (which throws
an exception) of the 'job' function will never get freed.
Imagine that in 'job' function you create a large amount of data, or
worse you create a database connection, which will be opened forever.
Tested on Python 2.5.2 and 2.7(svn). On the contrary, Python 3.0 does
not have this issue (it frees variables of the 'job' function at the end
of except: block.)
As Python 2.X will be another long time with us, I think it should be
fixed to behave correctly (that is as in Python 3.)
birkenfeld commentedon Apr 1, 2009
This is not a question of "correct" behavior, but of documented
semantics. We can't change that semantics in 2.x, like we did for 3.x,
because many people rely on the exception variable being available after
the except clause finishes.
Closing as "won't fix."
Glin commentedon Apr 2, 2009
I'm not talking about exception variable, but about the variables in
local scope of function job() (in my example it is the variable 'a' of
class A).
Sorry, if I did not make myself clear.
birkenfeld commentedon Apr 2, 2009
I know, but that object is kept alive by the frame object that is kept
alive by the exception assigned to "e".
nikratio commentedon Jun 12, 2009
I just spend several days figuring out a problem that was caused by this
behaviour and in the process I really tried to read everything that
relates to destruction of objects and exception handling in Python.
Georg, could you give me a pointer where exactly these semantics are
documented?
Thanks!
birkenfeld commentedon Jun 17, 2009
Well, it's the basic principle that an object is not destroyed until
there are no more references to it. The documented semantics I referred
to are that a variable assigned to in an "except X, Y" clause lives
beyond the scope of that clause.