Exception _abc_impl is set to a wrong type when using format_exception

[jato-c8y]

Bug report

Bug description:

Exception encountered during attempt to upgrade a C++ wrapper using the C API from Python 3.9 to 3.13.3.

Exception trace:

_abc_impl is set to a wrong type
<FrameSummary file python/3.13.3/lib/python3.13/traceback.py, line 155 in format_exception>
<FrameSummary file python/3.13.3/lib/python3.13/traceback.py, line 1406 in format>
<FrameSummary file python/3.13.3/lib/python3.13/traceback.py, line 993 in emit>
<FrameSummary file python/3.13.3/lib/python3.13/traceback.py, line 1259 in format_exception_only>
<FrameSummary file <frozen abc>, line 119 in __instancecheck__>

Details:
Exception is seen on attempt to use format_exception from the traceback module.
Previously we were using PyErr_Fetch to get type, value and traceback of the Exception.
We note the signature change of format_exception requires an Exception object.
We switched to use PyErr_GetRaisedException and pass this to format_exception.
We have a class that stores the exception reference object from PyErr_GetRaisedException which is then used to rethrow the exception to be caught in our code.
The catch then uses a callable function to the imported traceback module to invoke format_exception with the exception object. We then see the above exception stack. format_exception(py::make_tuple(e.getException())); Where getException returns the Exception object reference stored.

We have been unable to reproduce this in a Python script yet.

Checked the callable and is as expected <function format_exception at 0x7fda88878720>.
Checked the initial caught exception object and can print the 'what' as Exception('Thrown exception from static init').
Checked the initial caught exception is of type <class 'Exception'>.
Confirmed signature of format_exception using the inspect module and parameters confirmed as exc, value, tb, limit, chain, kwargs

We are running in a sub-interpreter with the GIL taken prior to the try, catch that sees this exception.

We are hoping the above is enough to spot a potential issue or anti-pattern.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[picnixz]

Can you give us the C code that triggers this issue? or at least a prototype and not with just words please? it's hard to track down the flow.

cc @ZeroIntensity

[ZeroIntensity]

Yeah, it'd be nice to see some code.

We are running in a sub-interpreter with the GIL taken prior to the try, catch that sees this exception.

It's hard to say without seeing code, but my best theory is that you're taking the GIL of the main interpreter and then trying to raise it in a subinterpreter, or vice versa. Are you using PyGILState_Ensure, by any chance?