[Python-bugs-list] [ python-Bugs-815648 ] thread unsafe file
objects cause crash
SourceForge.net
noreply at sourceforge.net
Wed Oct 1 02:32:16 EDT 2003
Bugs item #815648, was opened at 2003-09-30 23:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815648&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Olderdissen (janixia)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread unsafe file objects cause crash
Initial Comment:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815648&group_id=5470
More information about the Python-bugs-list
mailing list