readline.c: endless loop on SIGWINCH when loaded twice

[blueyed]

BPO	41033
Nosy	@blueyed

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-06-19.09:43:54.160>
labels = ['3.8', '3.9', '3.10', '3.11', 'extension-modules', '3.7', 'type-crash']
title = 'readline.c: endless loop on SIGWINCH when loaded twice'
updated_at = <Date 2021-12-17.16:28:49.989>
user = 'https://github.com/blueyed'

bugs.python.org fields:

activity = <Date 2021-12-17.16:28:49.989>
actor = 'blueyed'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2020-06-19.09:43:54.160>
creator = 'blueyed'
dependencies = []
files = []
hgrepos = []
issue_num = 41033
keywords = []
message_count = 4.0
messages = ['371861', '373394', '408754', '408796']
nosy_count = 2.0
nosy_names = ['blueyed', 'dale']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue41033'
versions = ['Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8', 'Python 3.9', 'Python 3.10', 'Python 3.11']

[blueyed]

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

cpython/Modules/readline.c

Lines 1111 to 1112 in 01ece63

	/* Set up signal handler for window resize */
	sigwinch_ohandler = PyOS_setsig(SIGWINCH, readline_sigwinch_handler);

.

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 5dbbf1a (3.5.2).

[blueyed]

91e1bc1 (bpo-41194) reminded me of this.
Maybe the same mechanism could be used here.

[dale]

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

[blueyed]

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.