Repository navigation
macOS: Test availability for dup3() and pipe2() to prevent crashes when building against Xcode 27 #153711
Description
Activity
- addedtype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
on Jul 14, 2026 - addedextension-modulesC modules in the Modules dirC modules in the Modules dir
on Jul 15, 2026 - added3.14bugs and security fixesbugs and security fixes3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixes3.13only security fixesonly security fixes
on Jul 17, 2026 - added a commit that references this issue
on Jul 26, 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.
-
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_PIPE2in configure. Turns out we do that for iOS already.- added a commit that references this issue
on Aug 5, 2026 - added a commit that references this issue
on 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!
Reacted by Hugo van KemenadeThanks for fixing & testing!
Let's use this issue for iOS as well.
- added a commit that references this issue
on Oct 1, 2026
Crash report
What happened?
This year's Apple OS releases (macOS/iOS/tvOS/watchOS/visionOS 27) add support for
dup3()andpipe2(). 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 passingac_cv_func_dup3=no ac_cv_func_pipe2=notoconfigure. The real fix will be to use availability checks inModules/posixmodule.cfordup3()andpipe2(), like gh-97897 doesPrototypes added to
sys/unistd.hin the *27 SDK:@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