Crash report
What happened?
AI Disclaimer: this issue was drafted by Claude Code, which also generated the reduced reproducer.
Emitting a warning while allocations are failing segfaults on a Py_DECREF of a NULL filename. setup_context() does not NULL-check PyUnicode_FromString("<sys>"), and the resulting NULL is later decref'd either by do_warn() (success path) or by setup_context()'s own handle_error: label (which uses Py_DECREF, not Py_XDECREF).
Reproducer
import _testcapi, warnings, faulthandler
faulthandler.enable()
warnings.simplefilter("always")
_testcapi.set_nomemory(0, 0) # fail every allocation from here on
warnings.warn("boom") # -> Py_DECREF(NULL) -> SIGSEGV
Deterministic (start=0). Reproduced on main.
Backtrace
#0 _Py_atomic_load_uint32_relaxed Include/cpython/pyatomic_gcc.h
#1 Py_DECREF Include/refcount.h
#2 do_warn Python/_warnings.c:1139 <- Py_DECREF(filename), filename == NULL
#3 warnings_warn_impl Python/_warnings.c:1184
#4 warnings_warn Python/clinic/_warnings.c.h:161
(gdb) frame 2; print filename → $1 = (PyObject *) 0x0.
Root cause
In setup_context() (_warnings.c), the f == NULL branch (~L1036):
if (f == NULL) {
globals = interp->sysdict;
*filename = PyUnicode_FromString("<sys>"); /* return value unchecked */
*lineno = 0;
}
Under memory pressure two allocations fail in sequence:
PyThreadState_GetFrame() returns NULL (its frame-object allocation fails), so the f == NULL branch is taken; then
PyUnicode_FromString("<sys>") itself returns NULL, leaving *filename == NULL.
The NULL *filename then reaches a Py_DECREF:
- if
setup_context() returns success (registry and __name__ already present in globals, so no further allocation is needed), do_warn() runs its cleanup Py_DECREF(filename) at L1139 — NULL deref; or
- if
setup_context() instead hits handle_error: (L1084), that path runs Py_DECREF(*filename) (L1087, not Py_XDECREF) — NULL deref.
Suggested fix
*filename = PyUnicode_FromString("<sys>");
if (*filename == NULL) {
goto handle_error;
}
and at handle_error: use Py_XDECREF(*filename) (since *filename may legitimately be NULL there).
Notes
Found by OOM-injection fuzzing (set_nomemory). Same pattern as gh-146080 (Py_DECREF(NULL) in an _ssl.c error label). Code is long-standing, so 3.13–3.15 are likely affected as well (unverified).
Found using fusil by @vstinner.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.16.0a0 (heads/main:bfecfcc2a86, Jun 18 2026, 13:48:35) [Clang 22.1.2 (1ubuntu1)]
Crash report
What happened?
AI Disclaimer: this issue was drafted by Claude Code, which also generated the reduced reproducer.
Emitting a warning while allocations are failing segfaults on a
Py_DECREFof a NULLfilename.setup_context()does not NULL-checkPyUnicode_FromString("<sys>"), and the resulting NULL is later decref'd either bydo_warn()(success path) or bysetup_context()'s ownhandle_error:label (which usesPy_DECREF, notPy_XDECREF).Reproducer
Deterministic (
start=0). Reproduced onmain.Backtrace
(gdb) frame 2; print filename→$1 = (PyObject *) 0x0.Root cause
In
setup_context()(_warnings.c), thef == NULLbranch (~L1036):Under memory pressure two allocations fail in sequence:
PyThreadState_GetFrame()returns NULL (its frame-object allocation fails), so thef == NULLbranch is taken; thenPyUnicode_FromString("<sys>")itself returns NULL, leaving*filename == NULL.The NULL
*filenamethen reaches aPy_DECREF:setup_context()returns success (registry and__name__already present inglobals, so no further allocation is needed),do_warn()runs its cleanupPy_DECREF(filename)at L1139 — NULL deref; orsetup_context()instead hitshandle_error:(L1084), that path runsPy_DECREF(*filename)(L1087, notPy_XDECREF) — NULL deref.Suggested fix
and at
handle_error:usePy_XDECREF(*filename)(since*filenamemay legitimately be NULL there).Notes
Found by OOM-injection fuzzing (
set_nomemory). Same pattern as gh-146080 (Py_DECREF(NULL)in an_ssl.cerror label). Code is long-standing, so 3.13–3.15 are likely affected as well (unverified).Found using fusil by @vstinner.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line:
Python 3.16.0a0 (heads/main:bfecfcc2a86, Jun 18 2026, 13:48:35) [Clang 22.1.2 (1ubuntu1)]