Creating multiple instances of faulthandler module causes unbalanced refcount on fatal_error.file

[stestagg]

Crash report

What happened?

In a DEBUG build:

import sys, faulthandler, gc

faulthandler.enable()
del sys.modules["faulthandler"]  # we still hold a ref to faulthandler above
import faulthandler

raises an abort from gc_decref due to negative reference counts.

This /is/ reproducible in non-debug builds (not the assert/abort, but subsequent use-after-free/segfault, but the reproducer is harder to pin down!)

With the help of chatgpt, we came up with the following guess of the root cause:

• _PyRuntime.faulthandler.fatal_error.file is a global singleton reference
• faulthandler.enable() sets this value to the relevant file ob
• Because faulthandler uses multi-phase init, then you can end up with 2 separate instances of the module.
• When gc runs on the faulthandler instances, they both Py_VISIT the fatal_error.file, causing invalid refcount calculations and the above abort.

Stack Trace

    frame #0: 0x0000ffffbdb8e13c libc.so.6`___lldb_unnamed_symbol_8e000 + 316
libc.so.6`___lldb_unnamed_symbol_8e000:
->  0xffffbdb8e13c <+316>: cmn    w0, #0x1, lsl #12 ; =0x1000
    0xffffbdb8e140 <+320>: csneg  w0, wzr, w0, ls
    0xffffbdb8e144 <+324>: b      0xffffbdb8e0bc ; <+188>
    0xffffbdb8e148 <+328>: mov    x0, x21
(lldb) bt
* thread #1, name = 'python', stop reason = signal SIGABRT
  * frame #0: 0x0000ffffbdb8e13c libc.so.6`___lldb_unnamed_symbol_8e000 + 316
    frame #1: 0x0000ffffbdb385fc libc.so.6`raise + 28
    frame #2: 0x0000ffffbdb22720 libc.so.6`abort + 44
    frame #3: 0x0000ffffbdb80a98 libc.so.6`___lldb_unnamed_symbol_808e0 + 440
    frame #4: 0x0000ffffbdb310d8 libc.so.6`__assert_fail + 184
    frame #5: 0x0000aaaae58931c0 python`visit_decref(op=0x0000ffffbd9747d0, data=<unavailable>) at gcmodule.c:277:9
    frame #6: 0x0000aaaae57896b4 python`dict_traverse(op=0x0000ffffbda2f2e0, visit=(python`visit_decref at gcmodule.c:269:1), arg=0x0000000000000000) at dictobject.c:2989:17
    frame #7: 0x0000aaaae5892b84 python`subtract_refs(containers=0x0000aaaae5ac1600) at gcmodule.c:296:16
    frame #8: 0x0000aaaae58944c0 python`collect(generation=2, n_collected=0x0000ffffe9e2d128, n_uncollectable=0x0000ffffe9e2d130, nofail=0) at gcmodule.c:853:5
    frame #9: 0x0000aaaae5894aa4 python`collect_with_callback(generation=2) at gcmodule.c:1025:14
    frame #10: 0x0000aaaae58952b8 python`PyGC_Collect at gcmodule.c:1570:13
    frame #11: 0x0000aaaae58952fc python`_PyGC_CollectIfEnabled at gcmodule.c:1584:12
    frame #12: 0x0000aaaae5864720 python`Py_FinalizeEx at pylifecycle.c:1189:5
    frame #13: 0x0000aaaae5752694 python`pymain_main(pymain=0x0000ffffe9e2d228) at main.c:3127:9
    frame #14: 0x0000aaaae5752798 python`_Py_UnixMain(argc=<unavailable>, argv=<unavailable>) at main.c:3160:12
    frame #15: 0x0000aaaae574aab4 python`main(argc=<unavailable>, argv=<unavailable>) at python.c:15:12
    frame #16: 0x0000ffffbdb22f1c libc.so.6`___lldb_unnamed_symbol_22ea0 + 124
    frame #17: 0x0000ffffbdb2305c libc.so.6`__libc_start_main + 156
    frame #18: 0x0000aaaae574a9b0 python`_start + 48

Bisect was able to reproduce this as far back as I could compile (3.7.17)
Found on a main non-debug aarch64 musl linux build, isolated on main debug aarch64 musl linux
reproduced on ubuntu aarch64 (as below)

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

Python 3.7.17 (tags/v3.7.17:ecd9946c9d1, May 9 2026, 01:29:57) [GCC 15.2.0]

[sergey-miryanov]

Can you reproduce this on newer versions? Python 3.7 has reached EOL and is no longer supported.

[stestagg]

yeah. it reproduces on main too.

3.7 was the earliest version I could compile easily when trying to find where it was introduced

[StanFromIreland]

3.7 was the earliest version I could compile easily when trying to find where it was introduced

In the future please note the latest version too.

[stestagg]

I mean, i did note in the main body and the "cpython versions tested on
" field.

the notes for that field say to mention in the body of multiple versions were tested. which is what i did.

The reason for highlighting 3.7 is because there were some changes to this module recently, and i wanted to show that they aren't likely to be related