pyrepl messed up terminal if a signal handler expects stdin

[gaogaotiantian]

Bug report

Bug description:

This is related to #129614 but more straightforward and irrelevant to pdb. (pdb needs this to be fixed though)

Start REPL from a terminal and do

import signal
signal.signal(signal.SIGINT, lambda s, f: input("test"))
<Ctrl+C>

Your terminal is messed up and newline won't work anymore. (Not the Python repl which will exit due to some run time error, the terminal itself is messed up)

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-130168: pyrepl can messup and poll is not thread safe #138617

[floor-licker]

I started looking into this but I'm just trying to better understand the issue first:

In general when using REPL, you would use exit() or Ctrl-D to exit.

I wasn't able to replicate the terminal being messed up, but just wanted to clarify:
In this case bug isn't that Ctrl+C isn't working, it's that trying to get user input from within a SIGINT handler while already in the REPL causes terminal corruption? What is the desired behaviour for when keyboard interrupt happens in this scenario?

[gaogaotiantian]

Ctrl+C is to trigger the SIGINT handler. The desired behavior is the terminal should not be messed up. (When the user hit <enter>, it should create a new line). I believe it's some internal state of pyrepl that's corrupted. pyrel does something tricky to support all the fancy features like multi-line editing so a lot of the inputs are intercepted and re-simulated.

[feoh]

@gaogaotiantian I think you may be onto something here, but the way you reported this bug leaves the reader confused as to your intent which makes un derstanding the actual issue more difficult.

I THINK what you're saying here is that, having intentionally stripped the default REPL signal handling by installing the dummy input("test") as a handler, which doesn't process the signal or stack frame arguments and doesn't do anything, you're saying that pyrepl should still recover and reset the terminal to a sane state.

Did I get that right?

[gaogaotiantian]

I don't know what exactly happened. I gave a very easy to reproduce example (at least on my machine). That's the duty of a bug reporter. It's the triager and the developer's duty to understand what happened behind the scene. So if my example does not reproduce, that's my responsibility to check if the steps are correct, otherwise I believe I'm off the hook :)

[feoh]

@gaogaotiantian I'm a first time contributor attempting to help out, so I apologize in advance if you feel like I'm making assertions about your on-the-hook-ness or not :)

@ambv said he'd try to find you (he thought you might be here at Pycon sprints) because as a general case it might not be feasible for Pyrepl to recover in the way you're expecting when you've stripped its default signal handler and left it in alternate mode.

At this point I'll stop commenting here. Thank you for understanding!

[gaogaotiantian]

Ah, I'm already back in my home. I did not participate in the sprint. It's okay that we consider this as not a bug, but it does crash pdb in some way.

I think the issue is - it's okay if pyrepl does not work, but the terminal itself does not work properly either. pyrepl should not crash the terminal itself (after the process even exits), that's undesired.

I hope you have a good experience in the sprint. I wish there are some easy to figure out issues for people who just started contributing.

[feoh]

@gaogaotiantian Sorry to hear I won't have the opportunity to meet you! I think that's why Lukasz hoped to talk to you, because there might be some special case code we could create that would enable pdb's specific use case in this regard.

[gaogaotiantian]

Well there are future chances :) I will go to the future PyCons so if you still come, feel free to grab me! I can talk with him about the potential fixes for this! In the mean time, looking for some other issues that interest you might also be a good idea!