php / php/php-src

CLI with async signal delivery, sometimes coredumps below php_XML_Parse

未关闭
#21,035 9 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

Bug Extension: libxml Status: Needs Triage
主要语言
C
星标
40.4k
派生
8.2k
平均合并
2 天 13 小时
30 天内合并 PR
96

描述

Description

A while ago I switched our production PHP CLI scripts to all have pcntl_async_signals enabled, along with a SIGALRM handler implementing every-minute runtime analytics gathering. Overall that has been working surprisingly well.

There is a rare yet repeating, and very specific, issue with certain XML processing scripts sometimes coredumping, with the stack always showing php_XML_parse calling into libxml2 in the middle, and then the alarm signal handler "hits".

I thought I'd not just try to paper over it by wrapping that XML usage in a sigblock, but report it here - maybe there is an easy fix to be had / issue to be uncovered? Or a suggestion for how to go about reproducing? As rare as it happens, I failed so far.

Could it be that the XML extension there leaves the engine in a state that makes reentry via the signal handler, problematic?

PHP is 8.4.16, previously 8.4.15

Here's the stack trace from the most recent event:

kernel: traps: php[703040] general protection fault ip:c2a3a1 sp:7ffe4f555970 error:0 in php[82a3a1,600000+6a2000]
systemd-coredump[745068]: Process 703040 (php) of user 30 terminated abnormally with signal 11/SEGV, processing...
systemd-coredump[745069]: Process 703040 (php) of user 30 dumped core.
Stack trace of thread 703040:
#0  0x0000000000c2a3a1 execute_ex (/opt/php/bin/php + 0x82a3a1)
#1  0x0000000000bd1de7 zend_call_function (/opt/php/bin/php + 0x7d1de7)
#2  0x0000000000bd20d5 _call_user_function_impl (/opt/php/bin/php + 0x7d20d5)
#3  0x0000000000943a00 pcntl_signal_dispatch (/opt/php/bin/php + 0x543a00)
#4  0x0000000000943aa9 pcntl_interrupt_function (/opt/php/bin/php + 0x543aa9)
#5  0x0000000000bd72e8 zend_interrupt_helper_SPEC (/opt/php/bin/php + 0x7d72e8)
#6  0x0000000000c2e988 ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (/opt/php/bin/php + 0x82e988)
#7  0x0000000000bd1de7 zend_call_function (/opt/php/bin/php + 0x7d1de7)
#8  0x0000000000bd2193 zend_call_known_function (/opt/php/bin/php + 0x7d2193)
#9  0x0000000000ada56f zend_call_known_fcc (/opt/php/bin/php + 0x6da56f)
#10 0x00007f06a37f9cc9 n/a (libxml2.so.16 + 0x42cc9)
#11 0x00007f06a38017a0 xmlParseChunk (libxml2.so.16 + 0x4a7a0)
#12 0x0000000000ade43d php_XML_Parse (/opt/php/bin/php + 0x6de43d)
#13 0x0000000000ad87ed xml_parse_helper (/opt/php/bin/php + 0x6d87ed)
#14 0x0000000000c27f92 ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (/opt/php/bin/php + 0x827f92)
#15 0x0000000000c2ef3e zend_execute (/opt/php/bin/php + 0x82ef3e)
#16 0x0000000000c97464 zend_execute_script (/opt/php/bin/php + 0x897464)
#17 0x0000000000b0f2cb php_execute_script_ex (/opt/php/bin/php + 0x70f2cb)
#18 0x0000000000c990a1 do_cli (/opt/php/bin/php + 0x8990a1)
#19 0x0000000000670acf main (/opt/php/bin/php + 0x270acf)
#20 0x00007f06a202b2fb __libc_start_call_main (libc.so.6 + 0x2b2fb)
#21 0x00007f06a202b3cb __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2b3cb)
#22 0x0000000000671ec5 _start (/opt/php/bin/php + 0x271ec5)
ELF object binary architecture: AMD x86-64
PHP Version
PHP 8.4.16 (cli) (built: Jan  3 2026 13:50:46) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.16, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.16, Copyright (c), by Zend Technologies
Operating System

openSUSE Tumbleweed 20260101

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

首先跟踪 pcntl_interrupt_function 与堆栈中显示的 XML 路径之间的交互:php_XML_Parse、xml_parse_helper 以及 libxml2 的 xmlParseChunk。使用带有 pcntl_async_signals、SIGALRM 处理程序和报告中的 XML 工作负载的 PHP 8.4.16 CLI,调查是否可以复现崩溃。确定失败原因并提供经过验证的修复或复现指导后,即视为完成。

由索引模型根据 Issue 内容生成。

评估

技术栈
php
领域
cli
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
停滞
描述清晰度
需要澄清
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。