Hirokazu Yamamoto <ocean-c...@m2.ccsnet.ne.jp> added the comment: I saw value of local variable *thread* was 5384 and internal buffer's address was 0x102618c8 (sorry, this is another stacktrace which differs from previous one)
thread(5384) func(file_close): enter.... thread(5384) func(close_the_file): enter.... thread(5384) func(close_the_file): file(00A1FB18) address(00B18FD0): local_close enter... thread(5376) func(file_close): enter.... thread(5376) func(close_the_file): enter.... thread(5376) func(close_the_file): leave.... thread(5376) func(file_close): file(00A1FB18) address(00B18FD0): PyMem_Free thread(5376) func(file_close): leave.... Thread 5384 entered close_the_file() and ran local_close() and allowed another thread to run. Before this, fp->f_fp was set to NULL. Thread 5376 entered close_the_file() and see fp->f_fp is NULL, and returned immediately and freed fp->f_setbuf. Interesting point is, thread 5384 was still running close(2), so flush(2) called by this function touched this buffer and crashed. ---------- Added file: http://bugs.python.org/file18051/py26_debug_threaded_close.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9295> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
