Faulthandler segfaults when called from threads

@vstinner

Crash report

What happened?

In a GILfull build of main, it's rarely possible to get faulthandler to segfault when calling it from threads. ~~Since it's a rare crash and I'm on mobile, no reduced test case is available at the moment.~~

Here's the traceback:

#0  _PyFrame_GetCode (f=0xfffff7fea1f0) at ./Include/internal/pycore_frame.h:94
#1  dump_frame (fd=fd@entry=2, frame=frame@entry=0xfffff7fea1f0)
    at Python/traceback.c:914
#2  0x000000000076254c in dump_traceback (fd=fd@entry=2,
    tstate=tstate@entry=0xaeb528 <_PyRuntime+329832>,
    write_header=write_header@entry=0) at Python/traceback.c:1007
#3  0x0000000000762710 in _Py_DumpTracebackThreads (fd=2,
    interp=<optimized out>, current_tstate=current_tstate@entry=0x0)
    at Python/traceback.c:1114
#4  0x00000000007773b4 in faulthandler_thread (unused=unused@entry=0x0)
    at ./Modules/faulthandler.c:631
#5  0x000000000075e77c in pythread_wrapper (arg=<optimized out>)
    at Python/thread_pthread.h:242
#6  0x0000fffff7def188 in start_thread () from /lib64/libc.so.6
#7  0x0000fffff7e5971c in thread_start () from /lib64/libc.so.6

Crash happened on ARM, if that's important.

Hmm, might be a duplicate of #128421.

Edit: reduced test case:

import faulthandler
from threading import Thread

for x in range(20):
    Thread(target=faulthandler.dump_traceback_later, args=(1e-10,)).start()

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.14.0a6+ (heads/main:55815a6474c, Mar 15 2025, 14:05:03) [GCC 11.5.0 20240719 (Red Hat 11.5.0-5.0.1)]

Hmm, might be a duplicate of #128421.

Probably not, that seems to be FT only. From what I know, faulthandler is notoriously buggy in multithreaded programs, and there's not much we can do to fix it.

I think this is a duplicate of #116008

I think this is a duplicate of #116008

Not EXACTLY same, but arises for the same reason yes, using python function _Py_DumpTracebackThreads() in multithreaded scenario without holding the GIL.

Closing in favor of #116008.

faulthandler was made more resistant to crashes with commit a84181c. The problem is that writing the thread name in faulthandler is now more likely to crash if the thread completed.

Example of pthread_getname_np() crash in gdb:

Thread 11 "Thread-5 (func)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9ade6c0 (LWP 442877)]
0x00007ffff7d31824 in pthread_getname_np@GLIBC_2.12 () from /lib64/libc.so.6
Missing rpms, try: dnf --enablerepo='*debug*' install glibc-debuginfo-2.41-11.fc42.x86_64
(gdb)

Navigation Menu

Repository navigation

Faulthandler segfaults when called from threads #131580

Crash report

What happened?

CPython versions tested on:

Operating systems tested on:

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

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Faulthandler segfaults when called from threads #131580

Description

Crash report

What happened?

CPython versions tested on:

Operating systems tested on:

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

Activity

ZeroIntensity commented on Mar 24, 2025

dgrisby commented on Mar 24, 2025

tom-pytel commented on Mar 25, 2025

devdanzin commented on Mar 25, 2025

vstinner commented on Nov 5, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions