GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Deadlock caused by type_lock_prevent_release() · Issue #155400 · python/cpython

Deadlock caused by type_lock_prevent_release() #155400

New issue
Copy link
New issue
Copy link
Closed
Closed
Deadlock caused by type_lock_prevent_release()#155400
Copy link
Labels
3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)release-blockertopic-free-threadingtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@nascheme
nascheme
opened on Aug 8, 2026
Issue body actions

Bug report

Bug description:

The current implementation of type_lock_prevent_release() has a flaw. If the critical section holds both TYPE_LOCK and the type dict mutex (this happens with BEGIN_TYPE_DICT_LOCK), then we can end up deadlocking. This is because only the type lock is prevented from being released and the dict mutex is released. This results in a lock inversion.

The suggested fix is to prevent release of both held by the top critical section.

Reproducer (note it depends on the memory addresses of the mutexes so not 100% reliable).

def test_concurrent_setattr_deadlock():
    # two threads assigning to a special method of the same
    # class could deadlock.  One thread held the type lock and waited for
    # the type dict mutex, which its critical section had released when it
    # blocked on the stop-the-world mutex, while the other held the type
    # dict mutex and waited for the type lock.
    class Base:
        pass

    N = 2000
    done = False

    def setter():
        func = lambda self: "x"
        while not done:
            Base.__repr__ = func
            try:
                del Base.__repr__
            except AttributeError:
                pass

    def subclasser():
        while not done:
            type('Sub', (Base,), {})()

    def lister():
        while not done:
            Base.__subclasses__()

    def basesetter():
        nonlocal done
        for i in range(N):
            if i % 100 == 0:
                print(i)

            class A:
                pass

            class C:
                pass

            class B(A):
                pass

            B.__bases__ = (C,)
        done = True

    # The setter threads are the ones that deadlock.  The others are there
    # to keep the type lock and the stop-the-world mutex contended, which
    # is what gets the setters into the window where it happens.
    targets = (
        setter,
        setter,
        subclasser,
        subclasser,
        lister,
        lister,
        basesetter,
    )
    threads = [Thread(target=target) for target in targets]
    for t in threads:
        t.start()
    for t in threads:
        t.join()

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

  • gh-155400: Fix deadlock with type_lock_prevent_release() #155401
  • [3.15] gh-155400: Fix deadlock with type_lock_prevent_release() (GH-155401) #155822

Activity

  1. nascheme
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    topic-free-threading
    on Aug 8, 2026
  2. nascheme
    added a commit that references this issue on Aug 8, 2026

    pythongh-155400: Fix deadlock with type_lock_prevent_release()

    18ff10e
  3. kumaraditya303
    added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
    3.15bugs and security fixesbugs and security fixes
    3.16new features, bugs and security fixesnew features, bugs and security fixes
    release-blocker
    on Aug 11, 2026
  4. github-project-automation
    added this to Release and Deferred blockers 🚫on Aug 11, 2026
  5. github-project-automation
    moved this to Todo in Release and Deferred blockers 🚫on Aug 11, 2026
  6. kumaraditya303
    added 2 commits that reference this issue on Aug 15, 2026

    Merge branch 'main' into pythongh-155400-type-lock-prevent-release-de…

    c299752

    gh-155400: Fix deadlock with type_lock_prevent_release() (#155401)

    50fcb91
  7. hugovk
    added a commit that references this issue on Aug 19, 2026

    [3.15] gh-155400: Fix deadlock with type_lock_prevent_release() (GH-1…

    e881073
  8. kumaraditya303
    closed this as completedon Aug 19, 2026
  9. github-project-automation
    moved this from Todo to Done in Release and Deferred blockers 🚫on Aug 19, 2026
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

    3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)release-blockertopic-free-threadingtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    • Release and Deferred blockers 🚫
      Status
      Done
      Show more project fields

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402520 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.