Skip to content

Crash when inspecting frame of other thread in free-threaded build #118680

Closed
Closed
Crash when inspecting frame of other thread in free-threaded build#118680
Labels
topic-free-threadingtype-crashA hard crash of the interpreter, possibly with a core dump

Description

@chgnrdv
chgnrdv
opened on May 7, 2024

Crash report

What happened?

Found when playing with #118415 (comment). Appears on both debug and non-debug builds.

import sys
import threading

l = threading._PyRLock()

def f():
    while True:
        with l:
            pass

t = threading.Thread(target=f)
t.start()
while True:
    f = sys._current_frames()[t.ident]
    while f:
        f.f_code
        f = f.f_back

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

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

Python 3.13.0a6+ (heads/main:9fd33af5ac, May 7 2024, 03:18:30) [GCC 10.2.1 20210110]

Activity

  1. chgnrdv
    added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on May 7, 2024
  2. mpage
    added
    topic-free-threading
    on May 7, 2024

  3. savannahostrowski commented on May 7, 2024

    @savannahostrowski
    savannahostrowski
    on May 7, 2024
    Member

    I can't reproduce the crash on a Mac (M3 Pro), in case that's helpful!

  4. erlend-aasland commented on May 7, 2024

    @erlend-aasland
    erlend-aasland
    on May 7, 2024
    Contributor

    I can repro on a MacBook Pro (M1), using ./configure --disable-gil --with-pydebug && make:

    $ ./python.exe ./crash.py
Assertion failed: (frame->frame_obj == NULL), function _PyFrame_MakeAndSetFrameObject, file frame.c, line 48.
[1]    27564 abort      ./python.exe ./crash.py
$ ./python.exe -VV
Python 3.13.0a6+ (heads/main-dirty:d3c7821335, May  7 2024, 09:27:50) [Clang 15.0.0 (clang-1500.3.9.4)]
$ ./python.exe -c "import sys; print(sys._is_gil_enabled())"
False

  5. colesbury commented on May 7, 2024

    @colesbury
    colesbury
    on May 7, 2024
    Contributor

    Yeah, this function is not thread-safe. We need to figure out what to do about it.

    More precisely, the call sys._current_frames() is okay, but accessing other thread's frames while they are running is not thread-safe without the GIL.

  6. colesbury commented on Nov 26, 2025

    @colesbury
    colesbury
    on Nov 26, 2025
    Contributor

    This was fixed by:

  7. colesbury
    closed this as completedon Nov 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic-free-threadingtype-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions