macOS now crashes fork() process instead of just warning output

Description

The latest macOS update has begun terminating certain fork() processes under specific circumstances. This is evidenced by the following screenshots and error logs

In the Nginx Error Log, we find multiple instances of "upstream prematurely closed connection" errors. The PHP Error Log indicates warnings about "__NSPlaceholderDate initialize" possibly running in another thread when fork() was invoked, and subsequently, child processes exiting prematurely.

• Nginx Error Log

[error] 1957#0: *2 upstream prematurely closed connection
[error] 50639#0: *77 upstream prematurely closed connection
[error] 28667#0: *16 upstream prematurely closed connection

• PHP Error Log

[27-Jul-2023 09:49:38] NOTICE: ready to handle connections
[27-Jul-2023 09:49:48] WARNING: [pool valet] child 54119 said into stderr: "objc[54119]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called."
[27-Jul-2023 09:49:48] WARNING: [pool valet] child 54119 said into stderr: "objc[54119]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug."
[27-Jul-2023 09:49:48] WARNING: [pool valet] child 54119 exited on signal 6 (SIGABRT) after 9.676681 seconds from start
[27-Jul-2023 09:49:48] NOTICE: [pool valet] child 54693 started
[27-Jul-2023 09:50:29] WARNING: [pool valet] child 54120 said into stderr: "objc[54120]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called."
[27-Jul-2023 09:50:29] WARNING: [pool valet] child 54120 said into stderr: "objc[54120]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug."
[27-Jul-2023 09:50:29] WARNING: [pool valet] child 54120 exited on signal 6 (SIGABRT) after 50.322856 seconds from start
[27-Jul-2023 09:50:29] NOTICE: [pool valet] child 54703 started

How to reproduce

Follow this step: https://github.com/laravel/valet/issues/1433#issuecomment-1653063304

Work Around (so far)

Rails users faced a similar issue a few years ago (refer to rails/rails#38560) and resolved it by introducing the environment variable

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES.

macOS php installed using Homebrew can achieve this by adding

	<key>EnvironmentVariables</key>
	<dict>
	    <key>OBJC_DISABLE_INITIALIZE_FORK_SAFETY</key>
	    <string>YES</string>
	</dict>

to PHP LauchDaemon plist homebrew.mxcl.php.plist. But ultimately it should be fixed in PHP itself.

PHP Version

PHP 8.2.8

Operating System

macOS 13.5

For People using Homebrew PHP

I've done much troubleshooting on this problem in Homebrew Issue (https://github.com/Homebrew/homebrew-core/issues/137431). If you have problems with your Homebrew PHP, please refer to it😉

Start with the Laravel Valet reproduction linked in the issue on PHP 8.2.8 and macOS 13.5, then review the PHP error logs around fork() and the OBJC_DISABLE_INITIALIZE_FORK_SAFETY workaround. Done should mean the affected child processes no longer abort under the reported macOS conditions without relying on that environment workaround.