Description
Crash report
What happened?
We currently save and load the stack pointer around _PyLong_Multiply/Add/Subtract. This is puzzling and is actually a bandaid around a more nefarious problem in the long/add/subtract functions.
In the new GC, all GC runs must either have no evaluating frame, or the GC must be able to see the current frame's stackpointer. This invariant does not hold true for the longobject functions once we remove the stack pointer saving around them. The problem is that the SIGCHECK https://github.com/python/cpython/blob/main/Objects/longobject.c#L114 macro in long objects check for pending signals (including the occasional GC run). This means a a long-running (ha) long function can trigger the GC. Reading the comments, I see that the goal is to check for keyboard interrupt signals, not necessarily run the GC in the middle of the function. We should fix this by only checking for pending signals, but not GC. This will also make long addition faster.
Removing the stackpointer setting actually causes test failures, so those failing tests can be used as regression tests.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Output from running 'python -VV' on the command line:
No response