[Bug]: SIGBUS core dumps in Laravel Horizon on Alpine ARM64 with PHP 8.5 and dd_writer_loop in backtrace
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 冷清
调研方向
在所描述的 PHP CLI 环境中复现崩溃：ARM64 上的 Alpine Linux 3.23，PHP 8.5.6，Laravel Horizon 或 scheduler，以及列出的 Datadog 扩展。先从 core dump 和 GDB backtrace 开始，然后检查 coms.c:1168 中的入口点 dd_writer_loop。完成的标准是确定 SIGBUS 的原因，并防止受影响的 CLI 进程反复生成 core dump。
由索引模型根据 Issue 内容生成。
描述
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
- 主要语言
- PHP
- 星标
- 558
- 派生
- 192
- 平均合并
- 2 天 11 小时
- 30 天内合并 PR
- 91
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
DataDog/dd-trace-php 的其他 Issue
-
难度 4/5 3-5 天 新手友好度 48/100
DataDog/dd-trace-php#4371 · 5 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
DataDog/dd-trace-php#4366 · 1 条评论 ·
维护者通常 1 天内回复
-
🐛 bug
难度 4/5 3-5 天 新手友好度 42/100
DataDog/dd-trace-php#4192 · 5 条评论 · 3 个 reaction ·
维护者通常 1 天内回复
-
🐛 bug
难度 4/5 3-5 天 新手友好度 38/100
DataDog/dd-trace-php#4042 · 10 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
feature-request
难度 4/5 3-5 天 新手友好度 48/100
DataDog/dd-trace-php#4031 · 2 条评论 ·
维护者通常 1 天内回复
查看 DataDog/dd-trace-php 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
OpenConext/OpenConext-engineblock#2168 ·
维护者通常 5 天内回复
-
mobile-app
难度 2/5 1-3 小时 新手友好度 74/100
Open-Locker/Open-Locker#352 ·
维护者通常 1 天内回复
-
[Bug]: SCIM Users groups[].value is returned as an integer, causing authentik user discovery to fail未关闭
难度 2/5 1-3 小时 新手友好度 62/100
grokability/snipe-it#20006 ·
维护者通常 1 天内回复
-
fixed
难度 2/5 1-3 小时 新手友好度 62/100
firefly-iii/firefly-iii#13150 · 2 条评论 ·
维护者通常 1 天内回复
-
type/bug
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复