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 再現環境を実行してクラッシュを観察し、その後、正常でない thread が再起動され、繰り返しリクエストを行ってもコンテナが実行を継続することを確認してください。

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.