Skip to content

Faulthandler segfaults when called from threads #131580

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
devdanzin opened this issue Mar 22, 2025 · 4 comments
Closed

Faulthandler segfaults when called from threads #131580

devdanzin opened this issue Mar 22, 2025 · 4 comments
Labels
extension-modules C modules in the Modules dir type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@devdanzin
Copy link
Contributor

devdanzin commented Mar 22, 2025

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)]

@devdanzin devdanzin added the type-crash A hard crash of the interpreter, possibly with a core dump label Mar 22, 2025
@picnixz picnixz added the extension-modules C modules in the Modules dir label Mar 22, 2025
@ZeroIntensity
Copy link
Member

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.

@dgrisby
Copy link
Contributor

dgrisby commented Mar 24, 2025

I think this is a duplicate of #116008

@tom-pytel
Copy link
Contributor

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.

@devdanzin
Copy link
Contributor Author

Closing in favor of #116008.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension-modules C modules in the Modules dir type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

5 participants