This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: readline.c: endless loop on SIGWINCH when loaded twice
Type: crash Stage:
Components: Extension Modules Versions: Python 3.11, Python 3.10, Python 3.9, Python 3.8, Python 3.7, Python 3.6, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: blueyed, dale
Priority: normal Keywords:

Created on 2020-06-19 09:43 by blueyed, last changed 2022-04-11 14:59 by admin.

Messages (4)
msg371861 - (view) Author: daniel hahler (blueyed) * Date: 2020-06-19 09:43
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).
msg373394 - (view) Author: daniel hahler (blueyed) * Date: 2020-07-09 11:13
91e1bc18bd (bpo-41194) reminded me of this.
Maybe the same mechanism could be used here.
msg408754 - (view) Author: Dale (dale) Date: 2021-12-17 06:33
I hit this on macOS today but I didn't get segmentation fault, at least not for as long as I cared to let Python run.  Instead I got a non-responsive Python process using 100% CPU that I had to kill with ^\.  I first hit this with GNU readline while running Python interactively under Emacs, then I reproduced it with libedit readline under a regular old terminal using the above recipe.

macOS 11.6.1, x86-64, Python 3.10.1 from MacPorts
msg408796 - (view) Author: daniel hahler (blueyed) * Date: 2021-12-17 16:28
Yes, the example also does not segfault for me either (also with Python 3.8.12 I have now as `python3.8`), so this was likely only happening in the more complex setup, and/or maybe with some specific version of readline back then.
History
Date User Action Args
2022-04-11 14:59:32adminsetgithub: 85205
2021-12-17 16:28:49blueyedsetversions: + Python 3.11
2021-12-17 16:28:41blueyedsetmessages: + msg408796
title: readline.c: SEGFAULT on SIGWINCH when loaded twice -> readline.c: endless loop on SIGWINCH when loaded twice
2021-12-17 06:33:01dalesetnosy: + dale
messages: + msg408754
2020-07-09 11:13:29blueyedsetmessages: + msg373394
2020-06-19 09:43:54blueyedcreate