Skip to content

macOS: Test availability for dup3() and pipe2() to prevent crashes when building against Xcode 27 #153711

Description

@mrpippy

Crash report

What happened?

This year's Apple OS releases (macOS/iOS/tvOS/watchOS/visionOS 27) add support for dup3() and pipe2(). When building for macOS using Xcode 27 beta but running on macOS 26, configure detects these functions, but Python crashes when it tries to use them. As a temporary fix, I'm passing ac_cv_func_dup3=no ac_cv_func_pipe2=no to configure. The real fix will be to use availability checks in Modules/posixmodule.c for dup3() and pipe2(), like gh-97897 does

Prototypes added to sys/unistd.h in the *27 SDK:

__API_AVAILABLE(macos(27.0), ios(27.0), tvos(27.0), watchos(27.0), visionos(27.0))
int     dup3(int, int, int);
__API_AVAILABLE(macos(27.0), ios(27.0), tvos(27.0), watchos(27.0), visionos(27.0))
int     pipe2(int [2], int);

@ned-deily @ronaldoussoren

CPython versions tested on:

3.13

Operating systems tested on:

macOS

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

No response

Linked PRs

Activity

  1. added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Jul 14, 2026
  2. added
    3.14bugs and security fixes
    3.15bugs and security fixes
    3.16new features, bugs and security fixes
    3.13only security fixes
    on Jul 17, 2026
  3. added a commit that references this issue on Jul 26, 2026
  4. ned-deily commented on Aug 4, 2026

    @ned-deily
    Member

    To summarize, the pre-release SDK for macOS 27.0 has added support for the dup3() and pipe2() system calls which are now available on pre-releases of macOS 27. The currently supported branches of Python (3.10+) will attempt to use these system calls when building posixmodule.c if their presence is detected by autoconf tests in configure.

    When using the Apple-supplied build tools (Xcode 27 or the Command Line Tools for Xcode 27, both currently available developer and public betas) to build Python, this can cause problems in two situations:

    1. When building using the default macOS 27 SDK for deployment on a range of systems, for example, by setting MACOS_DEPLOYMENT_TARGET=11.0 to indicate the resulting binaries should work on macOS 11 through at least macOS 27.

    2. Customarily, new major releases of Xcode and the Command Line Tools are supported on the most recent releases of the previous macOS version and Apple usually pushes the new versions of the build tools as software updates to the previous macOS version once the new version is released, typically in mid-September. In this case, pre-release versions of the build tools are supported both of the current releases of macOS 26.x and on pre-releases of macOS 27. Once macOS 27 is released, Xcode 27 and CLT 27 will likely become the defaults on the then-current release of macOS 26 as well, meaning that the 27 SDK will become the default for builds on macOS 26 as well as 27. However when building on 26, the default deployment target is set to 26.x so that builds are by default targeted for the OS on which the build is running. This is then a special case of situation 1 above.

    So, once Xcode 27 and macOS 27 are released (perhaps mid-September):

    • building any supported Python on macOS 27 (or 26) for executing on macOS 27+ should be OK: support for dup3() and pipe2() will be detected at build time and be available at execution time

    • building Python 3.14+ on macOS 26 or 27 for macOS 26 or earlier will fail with clang compile errors like:

    ./Modules/posixmodule.c:12328:11: error: 'pipe2' is only available on macOS 27.0 or newer
    [-Werror,-Wunguarded-availability-new]

    This behavior was introduced by code for gh-100384 in 3.14 which promotes the default unguarded-availability warning to an error.

    • building Python 3.13 and earlier systems on macOS 26 or 27 for macOS 26 or earlier will only get unguarded-availability compile warnings which can be easily overlooked. If not noticed, the resulting executable can segfault if code paths resulting in calls to dup3() or pipe2() are used.

    • the same results will occur when building Python on macOS 27 targeted for earlier systems (for example, MACOSX_DEPLOYMENT_TARGET=15.0): compile errors for 3.14+, compile warnings and potential runtime segfaults for 3.13 and earlier.

    The solution is to protect all uses of dup3() and pipe2() with Apple availability macros and execution time guards for the presence of the weak-linked system call as is done elsewhere in posixmodule.c for other recently added system calls. IMHO, it should be backported to at least 3.14. For 3.13 and earlier supported systems, we could either do a full backport or consider at least backporting the unguarded warning-to-error promotion introduced by gh-100384.

  5. encukou commented on Aug 4, 2026

    @encukou
    Member

    For 3.13 and earlier supported systems, we could either do a full backport or consider at least backporting the unguarded warning-to-error promotion introduced by #100384.

    Another thing to consider for the old versions is undefining HAVE_DUP3 & HAVE_PIPE2 in configure. Turns out we do that for iOS already.

  6. added 2 commits that reference this issue on Aug 5, 2026
  7. added a commit that references this issue on Aug 5, 2026
  8. added a commit that references this issue on Aug 5, 2026
  9. added a commit that references this issue on Aug 5, 2026
  10. ned-deily commented on Aug 5, 2026

    @ned-deily
    Member

    For 3.15 and beyond, @encukou added full support for weaklinking of the new dup3() and pipe2() system calls for macOS builds, based on @Vamsi-klu's original PR. This allows building with the macOS 27 SDK targeting older systems and conditionally using the new calls if present at run time.

    For 3.14 and 3.13, since they are both further along in their life cycles, we took the simpler approach of not checking for the new calls at configure time on macOS, avoiding the need to add somewhat complicated weaklinking checking. This avoids the risk of runtime segfaults and maintains the status quo.

    Thanks everyone for their help!

  11. added 2 commits that reference this issue on Aug 5, 2026
  12. encukou commented on Aug 5, 2026

    @encukou
    Member

    Thanks for fixing & testing!

    Let's use this issue for iOS as well.

  13. reopened this on Aug 5, 2026
  14. added a commit that references this issue on Aug 5, 2026
  15. added a commit that references this issue on Aug 14, 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.13only security fixes3.14bugs and security fixes3.15bugs and security fixes3.16new features, bugs and security fixesOS-iosOS-macextension-modulesC modules in the Modules dirtype-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