Message371861
The following will crash due to the signal handler calling itself recursively:
```
import os, readline, signal, sys
del sys.modules["readline"]
import readline
os.kill(os.getpid(), signal.SIGWINCH)
```
This fixes it:
```
diff --git a/Modules/readline.c b/Modules/readline.c
index 081657fb23..174e0117a9 100644
--- a/Modules/readline.c
+++ b/Modules/readline.c
@@ -967,6 +967,7 @@ readline_sigwinch_handler(int signum)
{
sigwinch_received = 1;
if (sigwinch_ohandler &&
+ sigwinch_ohandler != readline_sigwinch_handler &&
sigwinch_ohandler != SIG_IGN && sigwinch_ohandler != SIG_DFL)
sigwinch_ohandler(signum);
```
It gets installed/saved in https://github.com/python/cpython/blob/01ece63d42b830df106948db0aefa6c1ba24416a/Modules/readline.c#L1111-L1112.
Maybe it could also not save it in the first place if it is itself / has been installed already.
Or, it could be uninstalled when the module is unloaded, if there is such a thing?
I've seen the crash initially in a more complex setup, where it is not really clear why/how the readline module gets initialized twice really, but the above appears to simulate the situation.
(Hints on where to break in gdb to see where/when a module gets unloaded would be appreciated)
Added in https://github.com/python/cpython/commit/5dbbf1abba89ef1766759fbc9d5a5af02db49505 (3.5.2). |
|
Date |
User |
Action |
Args |
2020-06-19 09:43:54 | blueyed | set | recipients:
+ blueyed |
2020-06-19 09:43:54 | blueyed | set | messageid: <1592559834.18.0.183747914407.issue41033@roundup.psfhosted.org> |
2020-06-19 09:43:54 | blueyed | link | issue41033 messages |
2020-06-19 09:43:54 | blueyed | create | |
|