[issue23592] SIGSEGV on interpreter shutdown, with daemon threads running wild

2020-03-09 Thread STINNER Victor


STINNER Victor  added the comment:

I believe that this issue cannot occur in Python 3.8 thanks for bpo-36475.

According to the backtrace, a thread does crash in PyEval_EvalFrameEx(). I 
understand that it's a daemon thread. To execute PyEval_EvalFrameEx(), a daemon 
thread must hold the GIL. With bpo-36475, a daemon thread now exits immediately 
instead of taking the GIL.

--
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> PyEval_AcquireLock() and PyEval_AcquireThread() do not handle 
runtime finalization properly.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23592] SIGSEGV on interpreter shutdown, with daemon threads running wild

2015-03-06 Thread A. Skrobov

A. Skrobov added the comment:

That's right; and working around this issue, by taming the daemon threads a 
bit, wasn't too difficult.

Still, if the daemon threads are part of the language, they shouldn't crash the 
interpreter process, I suppose?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23592
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23592] SIGSEGV on interpreter shutdown, with daemon threads running wild

2015-03-06 Thread Tim Peters

Tim Peters added the comment:

Nothing should ever crash the interpreter :-)  So this is a thoroughly 
legitimate bug report.

However, there's no way to guess whether _this_ crasher is easy to fix, or next 
to impossible.  Without a test program to provoke the error, there's little to 
go on.  If it were a common problem with daemon threads, I'd expect at least 
several reports of similar behavior over the decades.  So chances seem to favor 
that there's something unique about the specifics of what your daemon threads 
were doing to provoke it - and/or timing quirks specific to your platform.

--
nosy: +tim.peters

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23592
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23592] SIGSEGV on interpreter shutdown, with daemon threads running wild

2015-03-05 Thread A. Skrobov

New submission from A. Skrobov:

I'm observing that this line of code:

https://hg.python.org/cpython/file/ec9bffc35cad/Python/ceval.c#l3010

-- causes a SIGSEGV on interpreter shutdown, after running some really 
convoluted Python code with daemon threads running wild.

At the time of the crash, tstate-frame==NULL, and tstate-curexc_type points 
to an exceptions.UnboundLocalError

I can reliably reproduce the crash, but unfortunately I cannot provide a 
standalone reproducer.

I'm speculating that this case is due to some daemon threads carrying on 
running while their variables are being destroyed from underneath them.


The traceback is probably of little use, but adding it nevertheless:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4dc15940 (LWP 10317)]
0x004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at 
Python/ceval.c:3010
3010if (tstate-frame-f_exc_type != NULL)
(gdb) bt   
#0  0x004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at 
Python/ceval.c:3010
#1  0x004d6db2 in PyEval_EvalCodeEx (co=0x2be1d510, 
globals=0x2b9c62f0, locals=0x0, args=0x2f6e9bf8, argcount=2, 
kws=0x2f6e9c08, kwcount=0, defs=0x2be2fb78, defcount=1, closure=0x0)
at Python/ceval.c:3267
#2  0x004d9ac9 in fast_function (func=0x2be37648, 
pp_stack=0x4dc13c90, n=2, na=2, nk=0) at Python/ceval.c:4131
#3  0x004d96d8 in call_function (pp_stack=0x4dc13c90, oparg=1) at 
Python/ceval.c:4056
#4  0x004d4258 in PyEval_EvalFrameEx (f=0x2f6e9a60, throwflag=0) at 
Python/ceval.c:2681
#5  0x004d6db2 in PyEval_EvalCodeEx (co=0x2be26250, 
globals=0x2b9c62f0, locals=0x0, args=0x2ac81f48, argcount=2, 
kws=0x2ac81f58, kwcount=0, defs=0x2be2fe88, defcount=1, closure=0x0)
at Python/ceval.c:3267
#6  0x004d9ac9 in fast_function (func=0x2be39108, 
pp_stack=0x4dc14230, n=2, na=2, nk=0) at Python/ceval.c:4131
#7  0x004d96d8 in call_function (pp_stack=0x4dc14230, oparg=1) at 
Python/ceval.c:4056
#8  0x004d4258 in PyEval_EvalFrameEx (f=0x2ac81db8, throwflag=0) at 
Python/ceval.c:2681
#9  0x004d99af in fast_function (func=0x2ee97840, 
pp_stack=0x4dc14620, n=1, na=1, nk=0) at Python/ceval.c:4121
#10 0x004d96d8 in call_function (pp_stack=0x4dc14620, oparg=0) at 
Python/ceval.c:4056
#11 0x004d4258 in PyEval_EvalFrameEx (f=0xc47fe0, throwflag=0) at 
Python/ceval.c:2681
#12 0x004d99af in fast_function (func=0x2be396f0, 
pp_stack=0x4dc14a10, n=1, na=1, nk=0) at Python/ceval.c:4121
#13 0x004d96d8 in call_function (pp_stack=0x4dc14a10, oparg=0) at 
Python/ceval.c:4056
#14 0x004d4258 in PyEval_EvalFrameEx (f=0x2f67bdf0, throwflag=0) at 
Python/ceval.c:2681
#15 0x004d6db2 in PyEval_EvalCodeEx (co=0x2be26880, 
globals=0x2b9c62f0, locals=0x0, args=0x2ef75fd8, argcount=1, kws=0x0, 
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3267
#16 0x0056346e in function_call (func=0x2be395a0, 
arg=0x2ef75fb0, kw=0x0) at Objects/funcobject.c:526
#17 0x0042182c in PyObject_Call (func=0x2be395a0, 
arg=0x2ef75fb0, kw=0x0) at Objects/abstract.c:2529
#18 0x0042c0d0 in instancemethod_call (func=0x2be395a0, 
arg=0x2ef75fb0, kw=0x0) at Objects/classobject.c:2602
#19 0x0042182c in PyObject_Call (func=0x2eec5060, 
arg=0x2aacf060, kw=0x0) at Objects/abstract.c:2529
#20 0x004d8ceb in PyEval_CallObjectWithKeywords (func=0x2eec5060, 
arg=0x2aacf060, kw=0x0) at Python/ceval.c:3904
#21 0x0052358b in t_bootstrap (boot_raw=0x2fab9d78) at 
./Modules/threadmodule.c:614
#22 0x00342f00677d in start_thread () from /lib64/libpthread.so.0
#23 0x00342e4d49ad in clone () from /lib64/libc.so.6

--
components: Interpreter Core
messages: 237283
nosy: A. Skrobov
priority: normal
severity: normal
status: open
title: SIGSEGV on interpreter shutdown, with daemon threads running wild
type: crash
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23592
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23592] SIGSEGV on interpreter shutdown, with daemon threads running wild

2015-03-05 Thread Antoine Pitrou

Antoine Pitrou added the comment:

Yes, daemon threads are really dangerous because they may keep running while 
the interpreter has started releasing critical resources. Things have improved 
in 3.x compared to 2.x, though.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23592
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com