New submission from Marien Zwart:
A script spawning a single daemon thread calling print() in a loop (like the
attached) will usually hang on shutdown in Python 3.4.2 and hg rev
8d802fb6ae32. Attaching gdb at that point shows the following:
(gdb) thread apply all bt
Thread 1 (Thread 0x7fd927d58700 (LWP 30274)):
#0 sem_wait () at ../sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1 0x00000000005282fe in PyThread_acquire_lock_timed (lock=0x1c5ea30,
microseconds=microseconds@entry=-1,
intr_flag=intr_flag@entry=0) at Python/thread_pthread.h:352
#2 0x0000000000528414 in PyThread_acquire_lock (lock=<optimized out>,
waitflag=waitflag@entry=1)
at Python/thread_pthread.h:556
#3 0x0000000000567e4c in _enter_buffered_busy (self=0x7fd927bc2b48) at
./Modules/_io/bufferedio.c:327
#4 buffered_flush (self=0x7fd927bc2b48, args=<optimized out>) at
./Modules/_io/bufferedio.c:874
#5 0x000000000042822a in PyObject_Call (func=0x7fd9277b69d8, arg=<optimized
out>, kw=<optimized out>)
at Objects/abstract.c:2086
#6 0x00000000004290e4 in call_function_tail (args=0x7fd927b8d048,
callable=0x7fd9277b69d8) at Objects/abstract.c:2124
#7 callmethod (is_size_t=1, va=0x7fff5c6cf6b0, format=0x0,
func=0x7fd9277b69d8) at Objects/abstract.c:2193
#8 _PyObject_CallMethodId_SizeT (o=<optimized out>, name=<optimized out>,
format=0x0) at Objects/abstract.c:2279
#9 0x000000000042822a in PyObject_Call (func=0x7fd9277b6990, arg=<optimized
out>, kw=<optimized out>)
at Objects/abstract.c:2086
#10 0x0000000000428cc4 in call_function_tail (args=0x7fd927b8d048,
callable=0x7fd9277b6990) at Objects/abstract.c:2124
#11 callmethod (is_size_t=0, va=0x7fff5c6cf7e0, format=0x5b9924 "",
func=0x7fd9277b6990) at Objects/abstract.c:2193
#12 _PyObject_CallMethodId (o=o@entry=0x7fd927b5d3a8, name=name@entry=0x862b00
<PyId_flush>,
format=format@entry=0x5b9924 "") at Objects/abstract.c:2238
#13 0x000000000050a521 in flush_std_files () at Python/pylifecycle.c:488
#14 0x000000000050a5aa in Py_Finalize () at Python/pylifecycle.c:550
#15 0x000000000041fc92 in Py_Main (argc=-1, argv=0x1) at Modules/main.c:787
#16 0x000000000041be3c in main (argc=2, argv=<optimized out>) at
./Programs/python.c:69
The daemon thread has exited, and the main thread hangs trying to flush stdout.
I haven't fully tracked down what happens here, but I think it's this:
- daemon thread calls ENTER_BUFFERED on stdout
- daemon thread drops the GIL before writing to stdout
- main thread grabs the GIL and starts exiting
- main thread sets _Py_Finalizing, signaling daemon threads to exit
- main thread calls flush_std_files and drops the GIL
- daemon thread grabs the GIL and immediately exits, without reaching
LEAVE_BUFFERED
- main thread deadlocks trying to ENTER_BUFFERED the same file
If that is what happens, I don't really see how to fix it (it's an example of
daemon threads not releasing their resources, which the documentation warns
about). But it's obviously unfortunate if merely writing to stdout/err is such
a resource.
----------
components: Interpreter Core
files: dio.py
messages: 234615
nosy: marienz
priority: normal
severity: normal
status: open
title: Hang on interpreter shutdown if daemon thread prints to stdout
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37835/dio.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
