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

Aperta
  • Qualcosa non va?
#24,799 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, github-actions, php
Ambito
backend, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)

Lingua principale
C
Stelle
41.8k
Fork
8.5k
Merge medio
2g 13h
PR unite (30g)
145

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di php/php-src

Tutte le issue di php/php-src

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.