Since this is an internal bug fix, for a mostly a theoretical bug, that probably isn't noticeable without assertions enabled, I don't think it needs a news entry.

Since this is an internal bug fix, for a mostly a theoretical bug, that probably isn't noticeable without assertions enabled, I don't think it needs a news entry.

Oops, missed this comment. We do need a blurb entry here, since this is indeed user-facing. Some people (cough cough, Gentoo users) do compile Python in release mode with assertions enabled, so there is a chance of this happening in production. I'd suggest something like "Fix assertion failure wheninput is interrupted by another thread."

The general idea makes sense to me. Would you mind adding a test case?

Sure: I didn't initially because I can't figure out how to write a test that fails with the current version: interrupting theinput call so it returns with an exception set is easy enough, but to actually crash it needs another signal to be received after the first has been handled, but beforePyOS_Readline returns. OtherwisePyErr_Occurred() just immediately returns without running a handler, and so no assertion is triggered.

I don't really see any reliable way to achieve that with the signal handling code at present. The reproducer just spamsSIGINT repeatedly to hit that window, but that will cause problems if we try it in unit tests. So, I can certainly add a test that will exercise the code, but it won't actually fail even before the fix, so I'm not sure if it is worthwhile by itself.

One thing we could consider is adding an assertion check that no exception has been set right at the top ofPyErr_CheckSignals. It is not safe to call with an exception raised, but that is not checked with an assertion unless a signal is actually pending. If we check the assertion regardless of signal status it will trigger in this case, and be much more likely to catch errors like this in general.

In testing this all seems to work: the new test case crashes before the fix, works after the fix, and the rest of the test suite runs without any problems. I am hesitant about it though, given how wide an impact this would potentially have.

Oops, missed this comment. We do need a blurb entry here, since this is indeed user-facing. Some people (cough cough, Gentoo users) do compile Python in release mode with assertions enabled, so there is a chance of this happening in production. I'd suggest something like "Fix assertion failure wheninput is interrupted by another thread."

Fair enough, will add!