[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls (test_urllib fails when run multiple times)

Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 7.0 -> 8.0 pull_requests: +29545 status: open -> pending pull_request: https://github.com/python/cpython/pull/31404 ___ Python tracker

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls (test_urllib fails when run multiple times)

Change by STINNER Victor : -- title: Regression caused by CALL_FUNCTION specialization for C function calls -> Regression caused by CALL_FUNCTION specialization for C function calls (test_urllib fails when run multiple times) ___ Python tracker

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

STINNER Victor added the comment: > Regarding C extensions, I think clear documentation that extension authors > need to check for signals in any code that might run for a few hundred > microseconds or longer is the best approach. Python 3.10 doesn't require it. If you want to change Python

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Mark Shannon added the comment: > So it's also a threads scheduling issue, no? No, it isn't. The interpreter checks the eval breaker frequently enough. It checks on all back edges and on all calls to Python functions. The test probably needs to be fixed, or extended. It is signals sent from

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

STINNER Victor added the comment: > Signal handling in Python is asynchronous. > https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers See my previous comment: "CHECK_EVAL_BREAKER() matters for signals, but also multithreading (drop the GIL), asynchronous

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

STINNER Victor added the comment: It's also interesting to note that the implementation of os.kill() and signal.raise_signal() do *not* call PyErr_CheckSignal(). The following signal functions *do* call call PyErr_CheckSignal(): * signal.signal() * signal.pause() * signal.pthread_kill() *

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

STINNER Victor added the comment: > Is this a bug? In Python 3.10, the code works. In Python 3.11, it fails. It's a behavior change. IMO this change is unwanted. I expect that signals are handled "as soon as possible", *especially* if we receive it "during" an os.kill() call on the current

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Mark Shannon added the comment: Is this a bug? Signal handling in Python is asynchronous. https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers The example code tests whether the interpreter responds synchronously and immediately. If you add `for _in range(1):

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Ken Jin added the comment: A short summary (thanks to Victor's findings!): - os.kill(pid, signal.SIGINT) is specialized to CALL_NO_KW_FAST - CALL_NO_KW_FAST doesn't check eval breaker, so the signal is ignored - signal handler wasn't called, test fails I'd like to add tests for some of the

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Change by Ken Jin : -- keywords: +patch pull_requests: +29013 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30826 ___ Python tracker ___

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Ken Jin added the comment: Thanks @Victor for catching this and figuring it out. I had a hard time narrowing this down since I'm on Windows which doesn't support signals :(. I'll handle the required patch and tests. -- ___ Python tracker

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

STINNER Victor added the comment: It seems like the following target miss CHECK_EVAL_BREAKER(): TARGET(CALL_NO_KW_METHOD_DESCRIPTOR_FAST) TARGET(CALL_NO_KW_METHOD_DESCRIPTOR_O) TARGET(CALL_NO_KW_BUILTIN_FAST) TARGET(CALL_NO_KW_BUILTIN_O) TARGET(CALL_NO_KW_BUILTIN_CLASS_1)

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

STINNER Victor added the comment: The problem is that the optimization no longer checks for pending signals in TARGET(CALL_NO_KW_BUILTIN_FAST). The patch below fix my issue. I guess that other opcode needs an additional CHECK_EVAL_BREAKER(). diff --git a/Python/ceval.c b/Python/ceval.c

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls

Change by STINNER Victor : -- title: test_unittest: TestBreakSignalDefault.testInstallHandler() fails if run after TestBreak -> Regression caused by CALL_FUNCTION specialization for C function calls ___ Python tracker