Segfault of the whole process when restarting an unhealthy thread: SG(server_context) is read after ts_free_thread()

从 frankenphp.c 中的 php_thread() 开始，重点检查 ts_free_thread() 之后的重启路径，并审查 frankenphp_thread_index() 和 frankenphp_log_message()。运行提供的 Docker 复现程序以观察崩溃，然后验证不健康的线程会重启，并且容器在重复请求期间保持运行。

What happened?

Disclosure: this issue was analyzed and written with Claude Opus 5.5 (Anthropic). The reproducer, the gdb session and the patch test below were run as described.

In classic mode, when a bailout escapes php_request_shutdown() (or php_request_startup() fails), php_thread() marks the thread unhealthy, tears it down and starts a new one. The teardown calls ts_free_thread() and then logs "Restarting unhealthy thread" through frankenphp_log_message(), which reads SG(server_context). At that point the thread no longer has TSRM storage, so the read faults and the whole process segfaults: every PHP thread dies and in-flight requests are dropped, instead of one thread being restarted.

frankenphp.c (v1.12.7; identical on main at e8752fa):

#ifdef ZTS
  ts_free_thread();
#endif

  if (thread_is_healthy) {
    go_frankenphp_on_thread_shutdown(thread_index);
    return NULL;
  }

  frankenphp_log_message("Restarting unhealthy thread", LOG_WARNING);

  if (!frankenphp_new_php_thread(thread_index)) {
    /* probably unreachable */
    frankenphp_log_message("Failed to restart an unhealthy thread", LOG_ERR);
  }

static inline uintptr_t frankenphp_thread_index(void) {
  frankenphp_server_ctx *ctx = (frankenphp_server_ctx *)SG(server_context);
  return ctx == NULL ? thread_index : ctx->thread_index;
}

static void frankenphp_log_message(const char *message, int syslog_type_int) {
  go_log(frankenphp_thread_index(), (char *)message, syslog_type_int);
}

On Linux frankenphp.c is built without a static TSRMLS cache (ZEND_TSRMLS_CACHE_DEFINE() is only under PHP_WIN32), so SG(x) evaluates tsrm_get_ls_cache() + sapi_globals_offset on each access. ts_free_thread() ends with tsrm_tls_set(0), so tsrm_get_ls_cache() returns NULL and the read lands at sapi_globals_offset.

gdb on the stock dunglas/frankenphp:1.12.7-php8.5 image with the reproducer below:

Thread "php-0" received signal SIGSEGV, Segmentation fault.
   call   tsrm_get_ls_cache@plt
   mov    sapi_globals_offset(%rip),%rdx
=> mov    (%rax,%rdx,1),%rax
   test   %rax,%rax
   je     ...
   mov    (%rax),%rdi
rax            0x0
rdx            0x20
si_addr        0x20

The same instruction sequence faults at the same address in a separate build of FrankenPHP 1.12.7 against PHP 8.5.10 ZTS, where the backtrace also shows ts_free_thread() returning on that thread immediately before the fault.

This started in v1.12.4. #2293 (v1.12.2, fixing #2268) added the restart path, at a time when frankenphp_log_message() called go_log(thread_index, ...) directly. #2438 (v1.12.4, fixing #2339) routed it through frankenphp_thread_index(), which turned the log call that follows ts_free_thread() into this access.

Reproducer

A convenient trigger is an opentelemetry post hook that runs out of memory. A function's observer frame is popped only after its end handlers return, so a hook that bails out is run a second time by zend_observer_fcall_end_all() at the start of php_request_shutdown(), which has no zend_try around it. The second fatal error escapes request shutdown and the thread is marked unhealthy. Any other bailout that marks a thread unhealthy reaches the same code.

Dockerfile:

FROM dunglas/frankenphp:1.12.7-php8.5
RUN install-php-extensions opentelemetry
ENV SERVER_NAME=:80
ENV FRANKENPHP_CONFIG="num_threads 2"
COPY index.php /app/public/index.php

index.php:

<?php
OpenTelemetry\Instrumentation\hook(null, 'f', post: static function (): void {
    $x = str_repeat('x', (int) (memory_get_usage() + 256 * 1024 * 1024));
    echo strlen($x);
});

function f(): void { echo ''; } // an empty body gets optimized away and is never observed

f();

$ docker build -t fp-crash . && docker run -d --name fp-crash -p 127.0.0.1:8099:80 fp-crash
$ for i in 1 2 3 4 5; do curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8099/; done
$ docker inspect -f '{{.State.Status}} {{.State.ExitCode}}' fp-crash
exited 139

With num_threads 2, the container exited within the first three requests in each of four runs. With num_threads 1, one run kept the container up for 10 requests, but those requests appeared to hang rather than succeed (see #2558 below).

Expected: the unhealthy thread is replaced and the server keeps serving. Actual: the process exits on SIGSEGV (status 139).

Suggested fix

Log with the OS-thread-local thread_index on the path that runs after ts_free_thread(). The neighbouring go_frankenphp_on_thread_shutdown() and frankenphp_new_php_thread() calls already use it there:

  go_log(thread_index, (char *)"Restarting unhealthy thread", LOG_WARNING);

  if (!frankenphp_new_php_thread(thread_index)) {
    go_log(thread_index, (char *)"Failed to restart an unhealthy thread", LOG_ERR);
  }

With this change applied to the 1.12.7 build described above, a reproducer that made the unpatched build exit on the second request was survived for 8 consecutive requests, with the threads being restarted.

Related

• #2558 / #2595: when FrankenPHP is PID 1, a SIGSEGV in a PHP thread may leave the process up with a stuck thread instead of exiting, so this crash may show up as a hang.

Build Type

Docker (Debian Trixie)

Worker Mode

No

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

FrankenPHP v1.12.7 PHP 8.5.11 Caddy v2.11.4
PHP 8.5.11 (cli) (built: Sep 24 2026 19:07:36) (ZTS)
Zend Engine v4.5.11, with Zend OPcache v8.5.11
opentelemetry extension version 1.4.2 (installed with install-php-extensions)
Image: dunglas/frankenphp:1.12.7-php8.5 (Debian GNU/Linux 13 trixie), otherwise defaults
memory_limit=128M, opcache.enable=1

[PHP Modules] Core ctype curl date dom fileinfo filter hash iconv json lexbor libxml mbstring mysqlnd openssl opentelemetry pcre PDO pdo_sqlite Phar posix random readline Reflection session SimpleXML sodium SPL sqlite3 standard tokenizer uri xml xmlreader xmlwriter Zend OPcache zlib

Relevant log output

No log line precedes the exit: the process terminates with status 139 inside the "Restarting unhealthy thread" log call. The image does not log PHP errors by default (log_errors=0); with display_errors=1 the response body shows the "Allowed memory size ... exhausted" fatal error twice, the second time during shutdown.