Static builds: the bundled `parallel` extension replaces Go's SIGSEGV handler without SA_ONSTACK, turning recoverable faults into process crashes

[austinginder]

What happens

On the static builds, FrankenPHP dies a few times an hour under load (heavy WordPress admin requests, plugin installs/updates through WP_Upgrader) with:

signal 11 received but handler not on signal stack
fatal error: non-Go code set up signal handler without SA_ONSTACK flag

runtime stack:
runtime.throw(...)
runtime.sigNotOnStack(0xb, ...)
runtime.adjustSignalStack2(0xb, ...)
runtime.sigtrampgo(0xb, ...)
...
goroutine N [syscall, locked to thread]:   (a PHP thread)

Each one takes the whole process down (~2 s restart under a supervisor). Before this was pinned down it looked like heap corruption in the upgrader, because that is the heaviest request most sites run.

Root cause

The default static extension set (defaultExtensions in build-static.sh) includes parallel. Its PHP_MINIT_FUNCTION(PARALLEL_SCHEDULER) (src/scheduler.c) installs a SIGSEGV handler with sa_flags = SA_SIGINFO and no SA_ONSTACK, replacing the handler the Go runtime installed. Its handler chains into Go's saved one from the ordinary thread stack, which the Go runtime rejects (sigNotOnStack). So any SIGSEGV in a PHP thread that Go would normally convert into a recoverable per-request panic becomes a process-wide fatal.

Read from a live process (v1.12.7, PHP 8.5.9 ZTS, parallel 1.2.15, macOS arm64, sigaction(sig, NULL, &old) via lldb):

Signal	Handler	sa_flags
SIGBUS / SIGABRT / SIGFPE	runtime.cgoSigtramp	SA_ONSTACK | SA_RESTART | SA_SIGINFO, mask all
SIGSEGV	php_parallel_sigsegv_handler	SA_SIGINFO only

Proof

Restoring Go's handler in the running process, sigaction(SIGSEGV, &php_parallel_old_sigsegv_action, NULL) (parallel keeps the previous action in that global; it is what its MSHUTDOWN does), and then repeating the same load: 10 heavy runs (four real Plugin_Upgrader::bulk_upgrade batches, several plugin-heavy admin sweeps) produced zero fatals on one unchanged pid. The identical load earlier the same day had produced nine.

Filed upstream as krakjoe/parallel#406 (add SA_ONSTACK to its flags).

Possible fixes on the FrankenPHP side

Any of these would close it independently of parallel's release cadence:

1. After php_module_startup() (in frankenphp.c), re-assert SA_ONSTACK on whatever handler is installed for SIGSEGV/SIGBUS: sigaction(sig, NULL, &sa); if (!(sa.sa_flags & SA_ONSTACK)) { sa.sa_flags |= SA_ONSTACK; sigaction(sig, &sa, NULL); }. This is the shape Go's cgo documentation asks of foreign handlers and protects against any other extension doing the same.
2. Drop parallel from defaultExtensions in build-static.sh (its worker threads are its own thread model, which is an unusual thing to want inside FrankenPHP's threads anyway).

Happy to send a PR for (1) if that is welcome.

[austinginder]

Follow-up: what the faults are once Go's handler is back

With SA_ONSTACK restored (same process, same load, ~3 more hours), the sigNotOnStack fatals are gone as reported above. What surfaces in their place is the underlying fault, now as a readable Go panic, and it is worth its own look because it is not recoverable either: it happens inside a cgo callback (go_sapi_flush), so the panic cannot cross back into C and the process still exits.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x100e42274]

goroutine 152 [running, locked to thread]:
bufio.(*Writer).Flush(...)
	.../go-xcaddy/src/bufio/bufio.go:636
net/http.(*chunkWriter).flush(0x1093d4500?)
	.../go-xcaddy/src/net/http/server.go:405 +0x44
net/http.(*response).FlushError(...)
	.../go-xcaddy/src/net/http/server.go:1719
net/http.(*ResponseController).Flush(0x76f2cd53b8f0?)
	.../go-xcaddy/src/net/http/responsecontroller.go:52 +0x12c
github.com/caddyserver/caddy/v2/modules/caddyhttp.(*responseRecorder).FlushError(0x1093d3900?)
	.../caddy/v2@v2.11.4/modules/caddyhttp/responsewriter.go:244 +0x38
net/http.(*ResponseController).Flush(...)
	.../go-xcaddy/src/net/http/responsecontroller.go:52
github.com/dunglas/frankenphp.go_sapi_flush(0x1f701?)
	/Users/runner/work/frankenphp/frankenphp/frankenphp.go:644 +0x390

v1.12.7 static build, PHP 8.5.9 ZTS, macOS arm64, php_server (non-worker) mode. Seen twice in three hours, both times at the moment a browser (Playwright-driven Chrome, HTTP/1.1, keep-alive) was closed while the WordPress admin app still had requests in flight. chunkWriter.flush dereferences cw.res.conn.bufw, which net/http nils in conn.finalFlush() once the connection is closed, so this is PHP flushing output on a request whose connection net/http has already finalized. The fc.clientHasClosed() && !fc.isDone guard in go_sapi_flush does not cover that ordering (frankenphp.go:635 on v1.12.7; the function is unchanged on main).

I could not reproduce it with curl -m aborts against a streaming script, single or 18 concurrent, so the window is narrower than a plain client abort; a keep-alive connection torn down with a response mid-flush is the shape that hits it here.

So the two fixes are complementary: parallel's flag turns this into a panic with a traceback instead of an opaque sigNotOnStack, but go_sapi_flush (and presumably the other write callbacks) also needs to tolerate a finalized connection, e.g. by recovering around the Flush call or by checking the request context is done before touching the writer.