CLI with async signal delivery, sometimes coredumps below php_XML_Parse

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

Beginne damit, die Interaktion zwischen pcntl_interrupt_function und dem im Stack gezeigten XML-Pfad nachzuverfolgen: php_XML_Parse, xml_parse_helper und xmlParseChunk aus libxml2. Verwende PHP 8.4.16 CLI mit pcntl_async_signals, einem SIGALRM-Handler und der gemeldeten XML-Workload, um zu untersuchen, ob sich der Absturz reproduzieren lässt. Als abgeschlossen gilt die Aufgabe, wenn die Ursache des Fehlers identifiziert ist und eine verifizierte Korrektur oder Anleitung zur Reproduktion verfügbar ist.