bug: malloc_consolidate heap corruption with 1.17.0 on FrankenPHP

[irhtml]

Bug report

After upgrading from dd-trace-php 1.16.0 to 1.17.0, we see glibc heap corruption in our FrankenPHP/Laravel Octane (long-running ZTS) production environment:

  malloc_consolidate(): unaligned fastbin chunk detected
  memory allocation of 3420891154821048684 bytes failed

The process crashes and requires a restart. Intermittent, affects ~20% of pods under production load.
We confirmed by comparing two Docker images identical in every way except dd-trace-php version:

Environment (identical between both images):

• PHP 8.4.19 (ZTS, Zend Memory Manager disabled)
• Debian 13 (trixie), x86_64
• FrankenPHP/Caddy 2.11.2 (serversideup/php:8.4-frankenphp)
• grpc ext 1.78.0
• redis ext 6.3.0

Results:

• dd-trace-php 1.16.0 - stable under production load
• dd-trace-php 1.17.0 - heap corruption under load

Profiling config: allocation profiling enabled, timeline enabled, CPU time profiling enabled.

Pinning back to 1.16.0 resolved the issue immediately.

PHP version

PHP 8.4.19 (ZTS) built Mar 16 2026

Tracer or profiler version

1.17.0

Installed extensions

Installed extensions: Core, ctype, curl, datadog-profiling, date, ddappsec, ddtrace, dom, fileinfo, filter, grpc, hash, iconv, json, libxml, mbstring, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, Phar, posix, random, readline, redis, Reflection, session, SimpleXML, sodium, SPL, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, Zend OPcache, zip, zlib

Output of phpinfo()

No response

Upgrading from

1.16.0

[realFlowControl]

Hey @irhtml 👋
thanks for opening this issue.
This looks to be related to php/frankenphp#2280 and #3414.
Are you able to reproduce this in a staging environment?
Asking because from #3414:

Most helpful would be a stacktrace, when the faulty allocation happens. (e.g., running FrankenPHP under gdb b _zend_bailout to set a breakpoint, then bt to gather the stacktrace.)

[irhtml]

Can give it a try tomorrow, we were not able to reproduce this in our staging env but that's probably because we do not have DD enabled there..

[realFlowControl]

I'll be on parental leave starting tomorrow, but my colleagues @bwoebi and @morrisonlevi will be here to help

[Kyotaro8224]

We also experienced a similar regression with 1.17.0 in a different environment:

• PHP 8.3 (NTS) + PHP-FPM
• memory_limit: 300M
• Symptom: PHP-FPM workers killed by SIGKILL (suspected OOM)
• Container memory did not appear to be saturated before the kill
• Pinning to 1.16.0 resolved the issue immediately

Profiling is not installed/loaded. Only APM tracing enabled via Remote Config.

[bwoebi]

@Kyotaro8224 I suppose an OOM is a different issue.

How quickly do you run OOM? Anything in particular consuming a lot of memory now (e.g. dd-ipc-helper before vs now)?

[Kyotaro8224]

@bwoebi

• Nothing in particular consuming a lot of memory — we didn't observe dd-ipc-helper or any specific process standing out. On 1.16.0, our ECS container (1GB memory limit) sits around 50% usage
• On 1.17.0, baseline memory usage jumped to around 80% with no other changes
• SIGKILL could happen on the very first requests after container start, or after a few minutes of serving traffic
• PHP-FPM could occasionally serve requests, but mostly failed to
• We also saw Allowed memory size of xxxxx bytes exhausted (tried to allocate xxxx bytes) errors intermittently
• Memory metrics did not show gradual increase — the kills appeared sudden
• We initially suspected our own code changes and rolled back, but the issue persisted — only after ruling out application code did we identify the tracer upgrade as the cause

Downgrading to 1.16.0 resolved all of these issues immediately.

[rytisder]

We can confirm the same behavior on our side.

Production started crashing only after upgrading the Datadog PHP tracer in a Laravel Octane + FrankenPHP setup. The failures were intermittent under load and looked like heap corruption / absurd memory allocation errors. Reverting to the older tracer version made the issue disappear.

[pedro-delacalzada-netex]

We can also confirm this using the official dunglas/frankenphp:1.12.1-php8.2-trixie image:

PHP 8.2.30 ZTS – Symfony 6.4

Fargate EKS replicas are being killed randomly with errors such as:

memory allocation of 7234307546237789535 bytes failed
memory allocation of 8083230630112817761 bytes failed

Downgrading from 1.17.0 solved the problem.

[bwoebi]

Is anyone able to grab a core dump with a backtrace? Sadly this error message alone doesn't help us, neither have we seen it ourselves yet.

[alexandrecruz]

Confirm behavior in Franken 1.10 - 1.12.1 using PHP 8.2

Solved by using DD_APM_INSTRUMENTATION_LIBRARIES=php:1.16.0 with install script

[morrisonlevi]

@alexandrecruz @pedro-delacalzada-netex @rytisder @Kyotaro8224 @irhtml Thank you all. I believe I have a fix in #3759. If any of you can try these artifacts to verify it's the same fix as your issue, I would appreciate it!

You just download and use this datadog-setup.php instead of the one from 1.17.0's release: https://s3.us-east-1.amazonaws.com/dd-trace-php-builds/1.18.0%2B433ca6085ff702f2426412706db7355ff9f221cf/datadog-setup.php. Its sha256 checksum is 6575941548fff835feb0c9c322da344fcec00f8fd7dc0b7a24f6665a08d37155.