[Bug]: SIGBUS core dumps in Laravel Horizon on Alpine ARM64 with PHP 8.5 and dd_writer_loop in backtrace

[ricdizio]

Bug report

We are seeing repeated native PHP crashes in a Laravel Horizon container when ddtrace and datadog-profiling are loaded.

The crashes generate large core.* files in the Laravel app working directory (/var/www). Each core dump is around 360–386 MB, and the container accumulated around 11 GB of core dumps before we noticed the issue.

This appears to affect PHP CLI processes used by Laravel Horizon and the scheduler, not the regular web container running the same Laravel application.

Environment

• Runtime: Docker container running in AWS ECS
• OS/base: Alpine Linux 3.23
• Architecture: ARM aarch64
• PHP binary: 8.5
• Application: Laravel app
• Queue worker: Laravel Horizon

PHP Version

PHP 8.5.6 (cli) (built: May 7 2026 16:54:58) (NTS)
Copyright (c) The PHP Group
Built by Alpine Linux aports
Zend Engine v4.5.6, Copyright (c) Zend Technologies
with Zend OPcache v8.5.6, Copyright (c), by Zend Technologies
with ddtrace v1.21.0, Copyright Datadog, by Datadog
with datadog-profiling v1.21.0, Copyright Datadog, by Datadog
with ddappsec v1.21.0, Copyright Datadog, by Datadog

After running gdb in one of the dump file, this is the output:

Reading symbols from /usr/bin/php85...
(No debugging symbols found in /usr/bin/php85)
warning: Can't open file /dev/shm/ddtl0-Rrui1dV7OsQ (deleted) during file-backed mapping note processing
warning: Can't open file /memfd:anon-handle (deleted) during file-backed mapping note processing
warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing
warning: Can't open file /dev/shm/ddtl0-J25GpquRtnQ (deleted) during file-backed mapping note processing
[New LWP 8618]
[New LWP 8620]
[New LWP 8621]
[New LWP 8619]
Core was generated by `/usr/bin/php85 '' '' '' '' '' '' '' '' '' '' '' '' '' '''.
Program terminated with signal SIGBUS, Bus error.
#0 0x000000aaaabca2de in ?? ()
[Current thread is 1 (LWP 8618)]

Backtrace:

#0 0x000000aaaabca2de in ?? ()
#1 0x0000aaaabc9aca24 in execute_ex ()
#2 0x0000aaaabc9acc4c in zend_execute ()
#3 0x0000aaaabcacf828 in zend_execute_script ()
#4 0x0000aaaabc8e8ef8 in php_execute_script_ex ()
#5 0x0000aaaabcad21c4 in ?? ()
#6 0x0000aaaabcad0d90 in ?? ()
#7 0x0000ffffb8e96f9c in libc_start_main_stage2 (main=0xaaaabcad0b04, argc=15, argv=0xffffcc186158) at src/env/__libc_start_main.c:95
#8 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread backtrace includes a Datadog writer thread:

(gdb) thread apply all bt
Thread 4 (LWP 8619):
#0 __syscall_cp_asm () at src/thread/aarch64/syscall_cp.s:28
#1 0x0000ffffb8ed848c in __syscall_cp_c (...) at src/thread/pthread_cancel.c:33
#2 0x0000ffffb8ed7618 in __futex4_cp (...) at src/thread/__timedwait.c:24
#3 __timedwait_cp (...) at src/thread/__timedwait.c:52
#4 0x0000ffffb8ed890c in __pthread_cond_timedwait (...) at src/thread/pthread_cond_timedwait.c:100
#5 0x0000ffffb4a5e160 in dd_writer_loop (_=) at /go/src/github.com/DataDog/apm-reliability/dd-trace-php/tmp/build_extension/tracer/coms.c:1168
#6 0x0000ffffb8ed946c in start (p=0xffff9f489b80) at src/thread/pthread_create.c:207
#7 0x0000ffffb8ed7864 in __clone () at src/thread/aarch64/clone.s:28

PHP version

8.5.6

Tracer or profiler version

1.21.0

Installed extensions

[PHP Modules]
apcu
bcmath
Core
ctype
curl
datadog-profiling
date
ddappsec
ddtrace
dom
fileinfo
filter
gd
hash
iconv
igbinary
intl
json
lexbor
libxml
mbstring
mongodb
msgpack
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_pgsql
pdo_sqlite
Phar
posix
random
readline
redis
Reflection
session
SimpleXML
soap
sockets
sodium
SPL
standard
tokenizer
uri
xml
xmlreader
xmlwriter
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache
datadog-profiling
ddappsec
ddtrace

Output of phpinfo()

No response

Upgrading from

No response

[morrisonlevi]

Thanks for the report. I believe you are hitting these issues in PHP because Alpine 3.23's php85 package uses the tailcall VM:

• Tailcall VM interrupt crash php/php-src#21922. This one was fixed in 8.5.7, but the package in Alpine 3.23.4's repository is only 8.5.6.
• Another tailcall vm_interrupt bug php/php-src#22265. This one hasn't merged yet, if we get it merged soon it will go out in 8.5.8.

If anyone is wondering if their PHP VM type is the tailcall VM, they can run this to find out:

# Output of 1 means it's the tailcall VM.
php -r 'echo (int)(ZEND_VM_KIND == "ZEND_VM_KIND_TAILCALL"), PHP_EOL;'

If you are hitting those bugs, then disabling CPU- and Wall-time in the profiler will significantly reduce your crashes. You can do so using the config mode of the datadog-setup.php script after installation:

# Your install line looks something like this:
php85 datadog-setup.php --enable-profiling --php-bin all

# Disable CPU- and Wall-time profiles due to Tailcall VM issues:
# https://github.com/php/php-src/pull/21922
# https://github.com/php/php-src/pull/22265
php85 datadog-setup.php config set --php-bin all \
    -d "datadog.profiling.wall_time_enabled=Off" \
    -d "datadog.profiling.experimental_cpu_time_enabled=Off"

Note that anything that sets a vm_interrupt including PHP's own execution time limit can cause this to crash, it's not restricted to the Datadog profiler. However, the time profiles will set an interrupt every 10ms, which is quite likely to lead to crashes.

Obviously, we are working hard to get these fixed upstream, as it's the only only real defense in this case.