Repository navigation
macOS: Test availability for dup3() and pipe2() to prevent crashes when building against Xcode 27 #153711
Description
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);
CPython versions tested on:
3.13
Operating systems tested on:
macOS
Output from running 'python -VV' on the command line:
No response
Linked PRs
- gh-153711: Guard dup3/pipe2 with __builtin_available on Apple platforms #154718
- gh-153711: Add runtime guards for dup3 & pipe2 #155174
- [3.15] gh-153711: Add runtime guards for dup3 & pipe2 (GH-155174) #155202
- [3.14] gh-153711: Avoid use of dup3 and pipe2 calls introduced in macOS 27 #155206
- [3.13] gh-153711: Avoid use of dup3 and pipe2 calls introduced in macOS 27 #155211
- gh-153711: Test availability for dup3() and pipe2() on iOS #155222
Activity
pythongh-153711: Fix os.pipe2 availability directive syntax
ned-deily commentedon Aug 4, 2026
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:
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.
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.
encukou commentedon Aug 4, 2026
Another thing to consider for the old versions is undefining
HAVE_DUP3&HAVE_PIPE2in configure. Turns out we do that for iOS already.gh-153711: Add runtime guards for dup3 & pipe2 (#155174)
[3.15] gh-153711: Add runtime guards for dup3 & pipe2 (GH-155174) (#1…
pythongh-153711: Avoid use of dup3 and pipe2 calls introduced in macO…
[3.14] gh-153711: Avoid use of dup3 and pipe2 calls introduced in mac…
[3.13] gh-153711: Avoid use of dup3 and pipe2 calls introduced in mac…
ned-deily commentedon Aug 5, 2026
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!
pythongh-153711: Test availability for dup3() and pipe2() on iOS
pythongh-153711: Test availability for dup3() and pipe2() on iOS
encukou commentedon Aug 5, 2026
Thanks for fixing & testing!
Let's use this issue for iOS as well.
[3.14] pythongh-153711: Avoid use of dup3 and pipe2 calls introduced …
pythongh-153711: Add runtime guards for dup3 & pipe2 (python#155174)
Fix bundled Python crashing on macOS 26 and older when built with Xco…