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

Đang mở
  • Có gì không ổn?
#24,799 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c, github-actions, php
Lĩnh vực
backend, testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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)

Ngôn ngữ chính
C
Star
41.8k
Fork
8.5k
Merge trung bình
2 ngày 13 giờ
Pull request đã merge (30 ngày)
145

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của php/php-src

Tất cả issue của php/php-src

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.