stack_limit_014.phpt segfaults on LINUX_X32_RELEASE nightly jobs since 2026-10-22

オープン
  • 何か問題がありますか？
#24,799 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, github-actions, php
領域
backend, testing

調査の方向性

Start with Zend/tests/stack_limit/stack_limit_014.phpt and compare its expected errors with the X32 release job logs linked in the issue. Investigate the difference between the failing X32 release jobs and the passing debug, PHP-8.2, and PHP-8.3 jobs, including the bailout change identified as a candidate. The issue is resolved when the test produces an expected error instead of Termsig=11 in the affected nightly jobs.

索引モデルが issue の本文から書いたものです。

説明

Description

Since the 2026-10-22 nightly, Zend/tests/stack_limit/stack_limit_014.phpt fails every night with Termsig=11 instead of one of the two expected errors, in LINUX_X32_RELEASE_NTS and LINUX_X32_RELEASE_ZTS on PHP-8.4, PHP-8.5, PHP-8.6 and master. The X32 debug jobs and PHP-8.2/8.3 pass, and every X32 job passed up to the 2026-10-21 nightly.

     %S%rMaximum call stack size of [0-9]+ bytes \(zend\.max_allowed_stack_size - zend\.reserved_stack_size\) reached|Allowed memory size of [0-9]+ bytes exhausted%r%s
002+
003+ Termsig=11

Between those two nightlies the job container (ubuntu:22.04, same digest sha256:0a9887…) and the runner image and kernel (ubuntu24/20261018.339, 7.0.0-1017-azure) did not change. On the PHP-8.4 side the relevant change is 3584a98bda ("Avoid state corruption via bailout"), merged in 8a94bb3822. So it is a candidate, but I have not been able to confirm it: PHP-8.3 has the same commit and passes.

I could not reproduce it outside GitHub Actions. In an ubuntu:22.04 container with the CI image digest, the apt-x32 and configure-x32 steps (--disable-debug --disable-zts), make install and the same environment variables, the test passes 5/5 both before and after 8a94bb3822 and on the current PHP-8.4 tip. It also passes with ulimit -s of 8M/64M/256M/unlimited, and within the whole Zend/tests run with -j10.

One difference that may matter: on the runner the test takes about 4.5 s (--show-slow in the logs), while locally it takes 0.08 s (0.5 s with a 256 MB stack). So on the runner it recurses much deeper before stopping, likely because of a larger detected stack or a different 32-bit address space layout under that kernel, and only then reaches the point where it crashes. Printing zend_test_zend_call_stack_get() in the X32 job would probably show this.

cc @arnaud-lb, since 3584a98bda changed how OOM is handled and this test accepts "Allowed memory size exhausted" as an outcome.

PHP Version

PHP-8.4, PHP-8.5, PHP-8.6 and master (nightly CI, X32 release builds)

Operating System

GitHub Actions ubuntu:22.04 container, i386 build (-m32 -msse2)

主要言語
C
スター
41.8k
フォーク
8.5k
平均マージ
2日 13時間
マージ済み PR（30日）
145

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

php/php-src のほかの issue

php/php-src の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。