Could you add the output of bt full from the GDB prompt after you've opened the core dump please?

Here it is

It seems we are affected by the same problem, as we're getting seemingly random segmentation faults since upgrading to Xdebug 3.3.1 (from Xdebug 3.2.x) on PHP 8.2.
Just as for the reporter, it also happens when there is no debug session ongoing.

Would it help to provide more data? If so, please provide information what is required (I'm not familiar with inspecting segmentation faults).

Can any of you reproduce this on the command line, with the run of a single request?

Preferably, you run it like:

USE_ZEND_ALLOC=0 gdb --args php script.php

(and then "run")

If that crashes, I am also interested in seeing the same, but run like:

USE_ZEND_ALLOC=0 valgrind php script.php

As so far, I can't reproduce this yet — although it does happen when an exception is thrown:

        tmp_str = {l = 4860617, a = 4862335, d = 0x55cb13ccf0e0 "\n\033[1m\033[31mDoctrine\\ORM\\Mapping\\MappingException\033[0m: Class \"Macroactive\\Core\\Common\\Domain\\Model\\Email\" is not a valid entity or mapped super class.\033[22m in \033[31m/www/platform/vendor/doctrine/orm/lib/"...} 

Perhaps this happens during auto loading?

Hi @derick,

Perhaps this happens during auto loading?

Nope, the crash happens during the tests execution so most likely this is some issue during the import? Weird though.

Hi @dercik,

The first command has crashed so please find attached the log of the running valgrind. Is this expected that tests passed and not crashed in this case??

In our case, I believe we haven't experienced a segmentation fault for command line scripts.
Only HTTP requests seem affected.

We're using the official 8.2-apache Docker image.

We are facing similar problems with PHP 8.0.30 and xdebug 3.3.1 in develop mode for HTTP requests. Couldn't reproduce in command line when quickly tested.

PHP error log indicated "exited on signal 11" without any lines written to xdebug log.

I have released Xdebug 3.3.1, which could have fixed this issue. Can you please try it?

Hi @derick, thanks for the update!

I think you meant 3.3.2, not 3.3.1. I have updated my docker image and still can see segfault on the same test suite. Do you need valgrind or gdb logs?

GDB shows a warning:

warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]

Not sure if it was present before.

Nothing has changed in the logs of the valgrind.
Attaching new logs.

Thanks, @derick, for releasing 3.3.2!

For us, the problem seems to be gone, i.e. there were no more segmentation faults since we updated to the new version.

Hi,
I am seeing something similar. Unfortunately, I am not able to provide that much helpful information but some key facts:

php --version

PHP 8.1.28 (cli) (built: Apr 24 2024 19:21:45) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.28, Copyright (c) Zend Technologies
with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans

We were running tests with PHPUnit 9.6.9 and they were also failing with status code 139. Rolling back to 3.2.2 helped.

Hope someone, who is more familiar will be able to share more insides, just wanted to share that the issue is still somewhere around

Looks like we found similar with Xdebug 3.3.2 and PHP 8.3.7. Again there is no debug session or profiling, Xdebug extension is just loaded.

The original reporter still has not yet a provided a way on how to reproduce this problem.

There are currently several reported crash bugs where more than one person added information, but often with a different cause. This makes researching this challenging, especially because I still do not have a reproducible case.

I am going to close this ticket (and the others), and will only accept issues related to crashes when there is a full reproducible case — the exact steps on how I could potentially try to have the same issue.