CLI with async signal delivery, sometimes coredumps below php_XML_Parse

[bof]

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

[Girgias]

Tagging @ndossche and @arnaud-lb as I wouldn't be surprised that libxml2 doesn't play nicely with signals.

[ndossche]

Would help if we know which version of libxml is used. Can you please share that? Also what is the callback doing?

[bof]

Would help if we know which version of libxml is used. Can you please share that? Also what is the callback doing?

Current openSUSE tumbleweed package name is libxml2-16-2.14.5-1.1.x86_64 + shared lib named libxml2.so.16.0.5, does that help?

The callback is jumping around a few classes gathering script sef measurements, then uses phpredis to push them to a localhost redis server, usually already connected.

[ndossche]

Reasonably modern libxml version at least.
The stacktrace actually seems to indicate that parsing the XML invokes some user code, and that user code is then interrupted by a signal. Do you have custom stream handling in user code that is used by the XML parser?