Skip to content
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

test_start_new_thread_failed flaky: failed on macOS (free threading) #127421

Open
colesbury opened this issue Nov 29, 2024 · 1 comment
Open

test_start_new_thread_failed flaky: failed on macOS (free threading) #127421

colesbury opened this issue Nov 29, 2024 · 1 comment
Labels
tests Tests in the Lib/test dir topic-free-threading type-bug An unexpected behavior, bug, or error

Comments

@colesbury
Copy link
Contributor

colesbury commented Nov 29, 2024

Bug report

Seen in https://github.com/python/cpython/actions/runs/12082953758/job/33695120037?pr=127399

======================================================================
FAIL: test_start_new_thread_failed (test.test_threading.ThreadTests.test_start_new_thread_failed)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/admin/actions-runner/_work/cpython/cpython/Lib/test/test_threading.py", line 1201, in test_start_new_thread_failed
    _, out, err = assert_python_ok("-u", "-c", code)
                  ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/Users/admin/actions-runner/_work/cpython/cpython/Lib/test/support/script_helper.py", line 182, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/Users/admin/actions-runner/_work/cpython/cpython/Lib/test/support/script_helper.py", line 167, in _assert_python
    res.fail(cmd_line)
    ~~~~~~~~^^^^^^^^^^
  File "/Users/admin/actions-runner/_work/cpython/cpython/Lib/test/support/script_helper.py", line 80, in fail
    raise AssertionError(f"Process return code is {exitcode}\n"
    ...<10 lines>...
                         f"---")
AssertionError: Process return code is -6 (SIGABRT)
command line: ['/Users/admin/actions-runner/_work/cpython/cpython/python.exe', '-X', 'faulthandler', '-I', '-u', '-c', 'if 1:\n            import resource\n            import _thread\n\n            def f():\n                print("shouldn\'t be printed")\n\n            limits = resource.getrlimit(resource.RLIMIT_NPROC)\n            [_, hard] = limits\n            resource.setrlimit(resource.RLIMIT_NPROC, (0, hard))\n\n            try:\n                _thread.start_new_thread(f, ())\n            except RuntimeError:\n                print(\'ok\')\n            else:\n                print(\'!skip!\')\n        ']

Linked PRs

@colesbury colesbury added type-bug An unexpected behavior, bug, or error tests Tests in the Lib/test dir topic-free-threading labels Nov 29, 2024
@serhiy-storchaka
Copy link
Member

As a temporary workaround, adding a small sleep in the else branch can help, but there should be better solution. This failure may be a symptom of existing bug.

mpage added a commit to mpage/cpython that referenced this issue Dec 3, 2024
mpage added a commit that referenced this issue Dec 3, 2024
Fix race in test_start_new_thread_failed

When we succeed in starting a new thread, for example if setrlimit
was ineffective, we must wait for the newly spawned thread to exit.
Otherwise, we run the risk that the newly spawned thread will race
with runtime finalization and access memory that has already been
clobbered/freed.

`_thread.start_new_thread()` only spawns daemon threads, which the runtime
does not wait for at shutdown, and does not return a handle. Use
`_thread.start_joinable_thread()` and join the resulting handle when
the thread is started successfully.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Dec 3, 2024
…27549)

Fix race in test_start_new_thread_failed

When we succeed in starting a new thread, for example if setrlimit
was ineffective, we must wait for the newly spawned thread to exit.
Otherwise, we run the risk that the newly spawned thread will race
with runtime finalization and access memory that has already been
clobbered/freed.

`_thread.start_new_thread()` only spawns daemon threads, which the runtime
does not wait for at shutdown, and does not return a handle. Use
`_thread.start_joinable_thread()` and join the resulting handle when
the thread is started successfully.
(cherry picked from commit 13b68e1)

Co-authored-by: mpage <mpage@meta.com>
mpage added a commit that referenced this issue Dec 3, 2024
#127574)

gh-127421: Fix race in test_start_new_thread_failed (GH-127549)

Fix race in test_start_new_thread_failed

When we succeed in starting a new thread, for example if setrlimit
was ineffective, we must wait for the newly spawned thread to exit.
Otherwise, we run the risk that the newly spawned thread will race
with runtime finalization and access memory that has already been
clobbered/freed.

`_thread.start_new_thread()` only spawns daemon threads, which the runtime
does not wait for at shutdown, and does not return a handle. Use
`_thread.start_joinable_thread()` and join the resulting handle when
the thread is started successfully.
(cherry picked from commit 13b68e1)

Co-authored-by: mpage <mpage@meta.com>
srinivasreddy pushed a commit to srinivasreddy/cpython that referenced this issue Jan 8, 2025
)

Fix race in test_start_new_thread_failed

When we succeed in starting a new thread, for example if setrlimit
was ineffective, we must wait for the newly spawned thread to exit.
Otherwise, we run the risk that the newly spawned thread will race
with runtime finalization and access memory that has already been
clobbered/freed.

`_thread.start_new_thread()` only spawns daemon threads, which the runtime
does not wait for at shutdown, and does not return a handle. Use
`_thread.start_joinable_thread()` and join the resulting handle when
the thread is started successfully.
ebonnal pushed a commit to ebonnal/cpython that referenced this issue Jan 12, 2025
)

Fix race in test_start_new_thread_failed

When we succeed in starting a new thread, for example if setrlimit
was ineffective, we must wait for the newly spawned thread to exit.
Otherwise, we run the risk that the newly spawned thread will race
with runtime finalization and access memory that has already been
clobbered/freed.

`_thread.start_new_thread()` only spawns daemon threads, which the runtime
does not wait for at shutdown, and does not return a handle. Use
`_thread.start_joinable_thread()` and join the resulting handle when
the thread is started successfully.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Tests in the Lib/test dir topic-free-threading type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants