This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Memory leak on open() only in 2.3?
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: nnorwitz Nosy List: brett.cannon, jdalambert, nnorwitz, rhettinger
Priority: normal Keywords:

Created on 2003-08-15 18:23 by jdalambert, last changed 2022-04-10 16:10 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
test.py jdalambert, 2003-08-15 18:23 Test file
fileobject.c.jdal jdalambert, 2003-08-16 23:09 Modified fileobject.c
Messages (10)
msg17797 - (view) Author: David Lambert (jdalambert) Date: 2003-08-15 18:23

If  for instance /tmp is a directory, then the follwing
code fragment produces a large memory leak on Python
2.3 compiled on Linux 2.4.20. This does not appear to
be a problem with previous versions of the interpreter.


#!/usr/local/bin/python


while 1:
    try:
        open('/tmp')
    except:
        pass

It appears that the exception IOError: [Error 21] Is a
directory leave garbage. If the parameter to open()
does not exist, the problem does not occur.
msg17798 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-08-15 20:07
Logged In: YES 
user_id=33168

Wow, it sure does leak!

Checked in as:  Objects/fileobject.c 2.180

Still needs a test.  Leaving open until I get around to it.
msg17799 - (view) Author: David Lambert (jdalambert) Date: 2003-08-16 23:09
Logged In: YES 
user_id=845425

I think I may have a fix. Check out the attached file. It
seems to work for me.
msg17800 - (view) Author: David Lambert (jdalambert) Date: 2003-08-19 13:52
Logged In: YES 
user_id=845425

Over the weekend and through Monday I ran my system 24/7
with the previously attached code. There do not seem to be
any problems, but I am waiting for your "blessing" before
considering it a fix.
msg17801 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-08-19 19:12
Logged In: YES 
user_id=33168

Your fix is the same as what I checked in, except that I
used Py_XDECREF instead of Py_DECREF, since
PyObject_CallFunction could fail and return NULL.  This
still needs a test and backport to 2.3.1.
msg17802 - (view) Author: David Lambert (jdalambert) Date: 2003-08-19 20:17
Logged In: YES 
user_id=845425

Good point, but if PyObject_CallFunction fails, is
PyErr_SetObject safe with a NULL second parameter? 
msg17803 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2003-09-06 23:10
Logged In: YES 
user_id=357491

Maybe?  =)

I just did a quick check and PyErr_SetObject (in Python/errors.c) 
calls PyErr_Restore in the same file that uses the 'value' argument 
to set the current PyThreadState's curexc_value which holds a 
PyObject.

But there are so many places where PyThreadState is used I don't 
feel up to hunting down where it might cause an issue.  Perhaps 
with more knowledge of the exception framework can answer the 
question.
msg17804 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-09-15 18:30
Logged In: YES 
user_id=80475

Did this fix get backported yet?
msg17805 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-09-15 18:34
Logged In: YES 
user_id=33168

No, I haven't had time to setup 2.3 branch in my cvs, test,
and check in.  Feel free to take it.
msg17806 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-10-28 21:22
Logged In: YES 
user_id=33168

Backport was made as Objects/fileobject.c 2.179.8.3 on
2003/09/16
History
Date User Action Args
2022-04-10 16:10:40adminsetgithub: 39073
2003-08-15 18:23:57jdalambertcreate