Thread.start() can hang indefinitely if the new thread fails (MemoryError) during its initialization

[ryv-odoo]

Bug report

Bug description:

There is a race condition in the threading module where a parent thread calling Thread.start() can wait forever if the newly created thread crashes with a MemoryError during its internal bootstrap process.

Case Explanation

In case we have a "Serving Thread" that creates threads on demand (e.g., for each HTTP request):

• When this Serving Thread calls Thread.start(), the OS-level thread (pthread_create()¹ - Linux) is successfully created. The parent thread then waits for the new thread to signal that it has started correctly by calling self._started.wait()².
• The new thread starts, but before it can signal the parent thread (Serving Thread) that it is alive with self._started.set()³ it encounters a MemoryError.
• This MemoryError can occur at the C level during the PyObject_Call to the _bootstrap method or inside the _bootstrap_inner method before _started.set() is reached, often due to memory pressure from other threads (or a heap limit being reached).
• This exception is caught by the C-level entry point thread_run(), which calls _PyErr_WriteUnraisableMsg⁴ and prints "Exception ignored in thread started by: ..."

The new thread then exits without ever signaling the _started event, and the parent thread waits indefinitely on the _started.wait().
This also leaves the threading module in an inconsistent state, as the "zombie" thread object may not be correctly cleaned up from the _limbo dict.

How to Reproduce

This has been observed in high-concurrency server applications under heavy, sustained load, where heap memory can be rapidly consumed and exhausted by concurrent threads ⁵.
This is a race condition that is difficult to reproduce reliably, as it requires triggering a MemoryError at a specific moment.

I found a (deterministic?) way to reproduce the issue by restricting the heap memory until it reaches a threshold where we can start a new thread, but this new thread won't get enough memory for its initialization.

On some machines (and depending of Python versions), it is sometimes necessary to tweak HARD_LIMIT_START / LIMIT_REDUCTION (I reproduced it on Ubuntu based machine with Python 3.11/3.12/3.13/3.14)

import resource
import threading
import gc

def handler():
    pass

def serving():
    # These should be tweak (depending of Python version + system)
    HARD_LIMIT_START = 30_000_000
    LIMIT_REDUCTION = 5_000

    for _ in range(500_000):
        gc.collect(2)  # Force getting back memory: seems to increase the determinism of the script

        # Limit the heap size available for this process
        resource.setrlimit(resource.RLIMIT_DATA, (HARD_LIMIT_START, HARD_LIMIT_START * 2))
        try:
            handler_thread = threading.Thread(target=handler)
            print(f'Start Thread: {handler_thread} - Heap size limit : {HARD_LIMIT_START}')
            handler_thread.start()
            handler_thread.join()
            HARD_LIMIT_START -= LIMIT_REDUCTION
        except RuntimeError as r:  # If Python refused to launch a new Thread
            print(f'RuntimeError: {r} - Cannot start the thread at all => error not detected.')
            return

serving_thread = threading.Thread(target=serving)
serving_thread.start()
serving_thread.join()

Expected Behavior

I am not sure if this is an "accepted" limitation of (CPython) Thread or not. IMO, Thread.start() shouldn't hang indefinitely if the low-level thread is dead.

I didn't take the time to try to fix it yet (if possible). I would prefer to get your opinions on this first.

CPython versions tested on:

3.12, 3.13, 3.14

Operating systems tested on:

Linux

Linked PRs

• gh-140746: Fix Thread.start() that can hang indefinitely #140799
• gh-140746: Fix Thread.start() that can hang indefinitely (alternative to GH-140799) #144750
• gh-140746: Fix Thread.start() hanging when the thread dies during bootstrap #153776

Footnotes

1. https://github.com/python/cpython/blob/25243b1461e524560639ebe54bab9b689b6cc31e/Python/thread_pthread.h#L284 ↩

2. https://github.com/python/cpython/blob/f463d05a0979aada4fadcd43ff721b1ff081d2aa/Lib/threading.py#L999 ↩

3. https://github.com/python/cpython/blob/f463d05a0979aada4fadcd43ff721b1ff081d2aa/Lib/threading.py#L1064 ↩

4. https://github.com/python/cpython/blob/89a79fc919419bfe817da13bc2a4437908d7fc07/Modules/_threadmodule.c#L1122 ↩

5. https://github.com/odoo/odoo/blob/350f7b10d4048b84d4a5f9e5aca9a88b8b971801/odoo/service/server.py#L273 ↩

[ZeroIntensity]

I would prefer to get your opinions on this first.

This seems like something that's worth fixing, especially if it's causing issues in production servers. Would you like to submit a PR?

[YvesDup]

On macOSX, the example did not fail as described (waiting for MemoryError or RuntimeError, if I understand correctly).
There is only a ValueError exception from the resource.setrlimit call.

[ryv-odoo]

This seems like something that's worth fixing, especially if it's causing issues in production servers. Would you like to submit a PR?

Thank you for the answer @ZeroIntensity. I will try to do it this week but I'm not sure I have the necessary skill to do it 😄

On macOSX, the example did not fail as described (waiting for MemoryError or RuntimeError, if I understand correctly). There is only a ValueError exception from the resource.setrlimit call.

It looks like setrlimit on macOSX might not work properly (see #78783).

There is a nondeterministic script to reproduce the error but I have no clue if it will be reproducible on MacOSX (you might need to launch it several time to see the issue).
⚠️ Be Careful before launching this script, it might crash your computer if you don't set a hard memory limit before launching the script (e.g. with ulimit command line: ulimit -v 1000000) ⚠️

import threading
import time

def memory_error():
    memory_issue_list = []
    while True:
        memory_issue_list.append("a" * 45000)

def handler():
    time.sleep(0.001)
    try:
        memory_error()
    except MemoryError:
        print(f"MemoryError in {threading.current_thread()}")

def serving():
    for _ in range(1_000):
        try:
            t = threading.Thread(target=handler)
            print(f'Start Thread: {t}')
            t.start()
        except RuntimeError:
            print('RuntimeError', {t})

serving_thread = threading.Thread(target=serving)
serving_thread.start()
serving_thread.join()

[ryv-odoo]

Hello @ZeroIntensity ,

I created a PR that fixes the issue: #140799. I don't like the fact it contains an arbitrary timeout but the fix is pragmatic, simple, and doesn't change any other behavior. What do you think about it ?

I tried another more distrubtive change where I moved the signal event (_started) to the C level. I added/used a handle_running PyEvent to the bootstate struct (in the same way as the handle_ready), but it slightly changes the semantics of Thread.start method since it will no longer wait that the child thread set its _ident/_native_id/os_name (also it removes the Thread._started, I'm not sure that is okay?). Here is the diff: https://github.com/python/cpython/compare/main...ryv-odoo:main-fix-140746-threading-start-waiting-c-alternative?expand=1

Thank you in advance.