Note: This may be a dupe or a generalization of 595601.




Running below code snippet on 2.3.1 release and debug 
build on Windows 2000/XP a few times will inevitably lead 
to a crash. 2.2.2 also exhibits this behavior.




The crashing code:




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


import thread




f=open("tmp1", "w")




def worker():


    global f


    while 1:


        f.close()


        f=open("tmp1", "w")


        f.seek (0, 0)




thread.start_new_thread(worker, ())


thread.start_new_thread(worker, ())


while 1: pass


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




The issue appears to be this (and similar) code sections 
from fileobject.c:




	Py_BEGIN_ALLOW_THREADS


	errno = 0;


	ret = _portable_fseek(f->f_fp, offset, whence);


	Py_END_ALLOW_THREADS




Note that due to 
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, 
f->f_fp can be set to NULL by file_close prior to entering 
_portable_fseek. Similar crashes can be observed with 
read, write and close itself when they are mixed with a 
concurrent close.




Obviously, the offending python code is buggy and a lock 
should be used to prevent concurrent access to f. 
However, it seems unreasonable for Python to crash 
because of it.




A mutex preventing concurrent access to the file object 
seems like a reasonable way to fix this.