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

未關閉
  • 哪裡不對？
#24,799 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
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 小時
30 天內合併 PR
145

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

php/php-src 的其他 Issue

查看 php/php-src 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。