Python 3.15rc2 on macos x86_64 creates additional thread at startup

Bug report

Bug description:

Python 3.15rc2 (from the official installer on macos x86_64 (rosetta emulation, not confirmed for native x86 hardware) creates a second thread at startup, causing any attempt to use os.fork with deprecation warnings enabled to emit a warning. This does not occur on arm64 builds or on non-macos platforms (tested linux and windows, x86 and arm).

Reproduction steps

Install python 3.15rc2 from https://www.python.org/downloads/release/python-3150rc2. Tested environment: M1 Macbook Pro running macos 26.6.2. Also observed on whatever github's macos-15 runner gives you.
Run arch -arm64 python3.15 -Werror -c 'import os; os.fork()'. See that no output is produced.
Run arch -x86_64 python3.15 -Werror -c 'import os; os.fork()'. It prints

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import os; os.fork()
               ~~~~~~~^^
DeprecationWarning: This process (pid=98584) is multi-threaded, use of fork() may lead to deadlocks in the child.

Expected results

A freshly started interpreter should not be running more than one thread and should be able to fork without warning.

CPython versions tested on:

3.15

Operating systems tested on:

macOS

Linked PRs

gh-157870: Do not count Rosetta's thread when warning about fork() with threads #158553

test: ignore the spurious fork() multi-threading warning on x86_64 macOS

The offending thread is not a python-managed thread: len(sys._current_frames()) is 1 regardless of architecture. os.fork uses a different OS API to count threads, and this one reports 2 on x86_64.

test: Ignore os.fork deprecation warning on macos x86_64

Thank you for the report. Here are a few initial observations.

This DeprecationWarning is not new to 3.15. You can reproduce the same warning with python.org universal2 installers going back to 3.12 when #100228 introduced this check for os.fork with multiple threads. However, note that there was a bug in that feature that skipped the deprecation message when using -Werror; that bug is fixed in 3.15 by #135427 and that fix was deliberately not backported to earlier releases to avoid potential compatibility issues. So to reproduce the warning on 3.12 through 3.14 systems, you need to not use the -Werror option.

The warning does not appear when the test is run on native Mac Intel systems using the same python.org installers. So it would appear it does have something to do with Rosetta 2 emulation, something we don't regularly test.

I also verified that it does not appear to have anything to do with CPython's framework build app bundle launcher; the warning appears in the same cases when directly invoking the Python executable, for example:

arch -x86_64 /Library/Frameworks/Python.framework/Versions/3.14/Resources/Python.app/Contents/MacOS/Python -c 'import os; os.fork()'

and also when using the Rosetta-forcing convenience executable, for example:

python3.13-intel64 -c 'import os; os.fork()'

I also was able to reproduce the same behaviors when using MacPorts universal builds of Python 13, 14, and 15.

Based on all this, this doesn't seem to warrant release blocker status. It should be investigated further but it may turn out to be something inherent to Rosetta 2 usage. But it does not seem to be an issue for running natively on either Apple Silicon or Intel Macs.

@gpshead

@gpshead @python/macos-team

This DeprecationWarning is not new to 3.15. You can reproduce the same warning with python.org universal2 installers going back to 3.12 when #100228 introduced this check for os.fork with multiple threads. However, note that there was a bug in that feature that skipped the deprecation message when using -Werror; that bug is fixed in 3.15 by #135427 and that fix was deliberately not backported to earlier releases to avoid potential compatibility issues. So to reproduce the warning on 3.12 through 3.14 systems, you need to not use the -Werror option.

Ah, I didn't know that. It just started showing up in my CI configuration with 3.15. I agree that it's not a release blocker (I'd probably agree with that even if the behavior were new in 3.15, since it's limited to an incorrect deprecation warning).

It does appear to be rosetta-related. It turns out that rosetta creates a thread named com.apple.rosetta.exceptionserver. I've found some references to this online but no official documentation.

Can we exclude any threads named com.apple.rosetta.exceptionserver from our count before showing the warning?

It just started showing up in my CI configuration with 3.15. I agree that it's not a release blocker (I'd probably agree with that even if the behavior were new in 3.15, since it's limited to an incorrect deprecation warning).

Thank you for testing the RC and reporting this! Now, before 3.15.0 final, is exactly when we do want to hear about things like this :)

Navigation Menu

Repository navigation

Python 3.15rc2 on macos x86_64 creates additional thread at startup #157870

Bug report

Bug description:

Reproduction steps

Expected results

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Python 3.15rc2 on macos x86_64 creates additional thread at startup #157870

Description

Bug report

Bug description:

Reproduction steps

Expected results

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

bdarnell commented on Sep 20, 2026

ned-deily commented on Sep 21, 2026

ned-deily commented on Sep 21, 2026

bdarnell commented on Sep 21, 2026

hugovk commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions