Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Local variables not freed when Exception raises in function called from cycle #49891

Closed
Glin mannequin opened this issue Apr 1, 2009 · 6 comments
Closed

Local variables not freed when Exception raises in function called from cycle #49891

Glin mannequin opened this issue Apr 1, 2009 · 6 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage

Comments

@Glin
Copy link
Mannequin

Glin mannequin commented Apr 1, 2009

BPO 5641
Nosy @birkenfeld
Files
  • notfreed.py: Example simulating issue
    		•

    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 = None
closed_at = <Date 2009-04-02.14:17:22.728>
created_at = <Date 2009-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 = <Date 2009-06-17.09:40:30.245>
user = 'https://bugs.python.org/Glin'

    bugs.python.org fields:

    activity = <Date 2009-06-17.09:40:30.245>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = <Date 2009-04-02.14:17:22.728>
closer = 'georg.brandl'
components = ['Interpreter Core']
creation = <Date 2009-04-01.08:49:37.495>
creator = 'Glin'
dependencies = []
files = ['13535']
hgrepos = []
issue_num = 5641
keywords = []
message_count = 6.0
messages = ['84989', '85025', '85189', '85202', '89306', '89449']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'Glin', 'nikratio']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'resource usage'
url = 'https://bugs.python.org/issue5641'
versions = ['Python 2.6', 'Python 2.5', 'Python 2.4', 'Python 2.7']
    @Glin
    Copy link
    Mannequin Author

    Glin mannequin commented 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.)

    @Glin Glin mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage labels Apr 1, 2009
    @birkenfeld
    Copy link
    Member

    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
    Copy link
    Mannequin Author

    Glin mannequin commented 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.

    @Glin Glin mannequin reopened this Apr 2, 2009
    @birkenfeld
    Copy link
    Member

    I know, but that object is kept alive by the frame object that is kept
    alive by the exception assigned to "e".

    @nikratio
    Copy link
    Mannequin

    nikratio mannequin commented 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
    Copy link
    Member

    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.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    1 participant
    @birkenfeld