I noticed that file_close() calls close_the_file(), then frees the
buffer for the file object.  However, close_the_file() may fail and
return NULL if the file object is currently in use by another thread, in
which case freeing the buffer from underneath the C stdio library may
cause a crash.

Here's the relevant bit of code from fileobject.c:

static PyObject *
file_close(PyFileObject *f)
{
        PyObject *sts = close_the_file(f);
        PyMem_Free(f->f_setbuf);
        f->f_setbuf = NULL;
        return sts;
}

I think the two middle lines of the function should be wrapped in an "if
(sts)" block.

Attached is a short program that causes python to crash on two of my
systems (Windows XP running Python 2.6.3 and Debian running Python 2.5)
and a patch with my proposed fix.

I think Python 3 is immune because the I/O code has been completely
rewritten.  I have not checked the Python 3 code to see if there are any
analogous problems in the new code, however.

Your proposal looks reasonable.
Two things:
- your patch should include an unit test (see Lib/test/test_file2k.py)
- fileobject.c should use tabs for indentation, not spaces

And you're right, py3k doesn't have this problem.

I reworked my test script into a unit test.  Thanks for pointing me to test_file2k.py.  I leveraged the infrastructure that was already there.

I've also uploaded a new patch that uses tabs instead of spaces, to match the rest of fileobject.c.

Is there anything more I can do to help get this crash-fix committed before 2.7 rc1?

Sorry, I had just forgotten. The patch has been committed in r81275 (trunk) and r81277 (2.6). Thank you: