View Issue Details

Jump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0002232XdebugUncategorizedpublic2023-12-27 09:502024-01-15 20:22
Reporteredsrzf Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionno change required 
OSDebianOS Version11.8 
Product Version3.3.1 
Summary0002232: Segmentation fault with Symfony dependency injection and ddtrace extension
Description

When trying to upgrade my Symfony application to XDebug 3.3.1, I experience a segmentation fault when making certain requests. It seems to be related to the service container based on the PHP stack trace. My code doesn't even get a chance to execute.

Other observations:

  • It only happens when the ddtrace extension is also installed and enabled.
  • It happens most often on the first request, when the service container needs to be dumped to PHP.
Steps To Reproduce

I've created a GitHub repository here, with steps to reproduce: https://github.com/edsrzf/xdebug-segfault

  • git clone git@github.com:edsrzf/xdebug-segfault.git
  • docker build -t xdebug-segfault .
  • docker run --rm xdebug-segfault

Notice that the exit code is 139, which indicates a segmentation fault. It doesn't output "Segmentation fault" on my machine when run this way, but if I create a shell in the container with docker run --rm -it xdebug-segfault /bin/bash, then run src/entry, I do see "Segmentation fault".

I tried to make the code as minimal as possible, but it still has a few Composer dependencies and multiple files. Apologies, but I definitely spent more than the "several hours" mentioned in the bug reporting guide getting to this point. :)

I imagine it should also be possible to reproduce on Linux outside of Docker as long as ddtrace is installed.

Additional Information

Output of php -v:

PHP 8.3.0 (cli) (built: Dec 19 2023 03:56:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.0, Copyright (c) Zend Technologies
with Xdebug v3.3.1, Copyright (c) 2002-2023, by Derick Rethans
with ddtrace v0.95.0, Copyright Datadog, by Datadog
with ddappsec v0.95.0, Copyright Datadog, by Datadog

I've attached full GDB backtrace and valgrind logs.

I've attached

TagsNo tags attached.
Operating SystemDebian 11.8
PHP Version8.2.0-8.2.9

Activities

derick

2024-01-02 17:55

administrator   ~0006747

When I try out your reproduce case, I only get:

derick@gargleblaster:/tmp/xdebug-segfault$ docker run --rm xdebug-segfault                                                                                                                                                                   
[critical] Uncaught Error: Class "Symfony\Component\Console\Application" not found

edsrzf

2024-01-02 19:15

reporter   ~0006748

What exit code do you see? That's the same output I get, but exit code is 139, indicating segfault.

As mentioned in the report, if I run within a shell, I do see "Segmentation fault":

$ docker run --rm -it xdebug-segfault /bin/bash
$ src/entry

derick

2024-01-08 18:22

administrator   ~0006753

I managed to reproduce it. I had to remove the cache first :-) After installing Xdebug from source in the Docker container, I could reproduce this and dial into the problem. I believe this patch fixes this, and CI is now testing it:

https://github.com/xdebug/xdebug/pull/946

derick

2024-01-10 18:24

administrator   ~0006761

So, my fix doesn't actually fix this, and I also can't reproduce this locally. Not even with ddtrace installed. I've spent a lot of time on this now, and don't know what is going on here. I have made a PR against your branch, where it pulls the Xdebug sources from my special branch. Please merge that, so that a further go at fixing this might succeed.

derick

2024-01-15 15:17

administrator   ~0006774

Hi,

After many hours of debugging with Bob from Datadog, this turned out not to be a bug in Xdebug, but rather in Datadog's tracer.

Xdebug switched from overloading the Zend engine function execute_ex to the more modern Observer API that was recently introduced in PHP. With execute_ex overloading it is up to the extension to call the original one from within the overloaded handler, but with the Observer API it is PHP that takes care of calling pre- and post-hooks.

The problem occurred here when Datadog's Trace, removed the post-hook incorrectly, rendering Xdebug's post-hook inoperable. This means that in some situations, this hook wasn't called, and Xdebug's idea of how the stack looked like had an extra item — which had already been freed. When Xdebug then tries to access data in this already freed stack frame, the crash occurs.

Datadog is working on a fix: https://github.com/DataDog/dd-trace-php/pull/2469, which should take care of fixing this.

As there is no bug in Xdebug, I am closing this report.

edsrzf

2024-01-15 20:22

reporter   ~0006780

Fantastic work! Thank you very much for the time spent resolving this!