Would you be able to provide an Xdebug log as well? It's explained at https://xdebug.org/reporting-bugs#step-debugger ?

We are experiencing the same issue as described. xdebug 3.2.2 is working fine, starting 3.3.0 we are having the issues.

I attached the xdebug log.

If there is anything else I can help with.

I have the same issue. Same docker: php:8.1-fpm
When I switch to xdebug-3.1.0 is works fine, but xdebug-3.3.1 doesn't work with this docker.

It seems that php:8.3-fpm + xdebug-3.3.1 works fine. ( I haven't verify it deeply, but at least such configuration doesn't cause described error. )

@cvirag, is that the whole output of bt? I believe it is missing many stackframes.

If anybody else can also make a bt, that would be great.

As so far, I haven't been able to reproduce this?

Hi Derick, could this bt be useful to you?

@cvirag, yes, a little. Can you, when you're at the (gdb) prompt also enter the following:

frame 2
p *extra_brk_info
p *extra_brk_info.filename
p (char*)extra_brk_info.filename.val
p *executed_filename
p (char*)executed_filename.val

If you have an xdebug.log file to go with this (see https://xdebug.org/reporting-bugs#step-debugger), that would be of great help too.

cheers,
Derick

Hi @derick, please find the xdebug log as well as the output of the additional gdb commands attached (I also included bt in xdebug_gdb_details.log).

The result of p *executed_filename is suspicious:

(gdb) p *executed_filename
Cannot access memory at address 0x7d31392d39

yes, it is. The interesting thing is that it works sometimes. I can't find a pattern when it crashes and when it does not though.

Hi @derick, I don't have reproduction steps to share, since it fails in various places in our codebase.

However, I narrowed it down to https://github.com/xdebug/xdebug/tree/91bfb654b0a6cfed63d327728db8ec2f3f82c97a

It works without issues on previous commit (a725dadae5c80187f5f3f0a0af7e316b874ef08d), and it also works on 3.3.1 if I revert this commit.

@deadrock, I am sure that reverting this speed-up will resolve the problem, but that's not a solution. For some reason zend_get_executed_filename_ex() returns bogus data, which is the real problem. So far, I haven't been able to reproduce this yet.

Can any of you reproduce this in a docker environment that you can share? @xedaxip791 perhaps, as your set-up is all public.

@derick I spent a bit more time debugging this, and came to the same conclusion, but at least revert allows us to continue using debugger as before.

At some point, (for function_name __invoke) executor_globals.current_execute_data->func->op_array.filename becomes 0x6465746300000040, which is not problem since executor_globals.current_execute_data->func->type equals 1, so zend_get_executed_filename_ex() returns filename of prev_execute_data.
However, when efree() is called in https://github.com/php/php-src/blob/af2110e664635329cbd7038727d4c7f222bb8a0e/Zend/zend_closures.c#L60, executor_globals.current_execute_data->func->type becomes 0, which means that zend_get_executed_filename_ex() returns filename of the current_execute_data, which points to the bogus address 0x6465746300000040.

(Not completely sure what the significance of the 0x6465746300000040 address it, but it's always the same.)

I have tried making a minimal reproduction case, but haven't succeeded yet.

I've tested this on php-8.1.27. If I try to build php with --enable-debug flag, the issue doesn't appear.

@deanrock — I tried with both debug and non-debug builds (of PHP 8.2.28-dev), but I can't even reproduce this in a big environment. If you can provide something even in a bug environment for me to try, then perhaps we can pinpoint this better. However, I might nearly consider this as a bug in PHP, as the zend_get_executed_filename_ex() function misbehaves?

@derick This (at least from what I observed) happens in xdebug_execute_internal, which is not used in PHP 8.2+ https://github.com/xdebug/xdebug/blob/3918dbabbc72211c0b8c7c5a873beef3faa27249/src/base/base.c#L1006.

I haven't managed to reproduce bogus filename pointer in xdebug_execute_begin / xdebug_execute_ex.

I've only been able to reproduce this in our company's PHP codebase, which I cannot share.

Right, it seems a PHP 8.1 (and 8.0) only issue. From PHP 8.2 and later Xdebug uses observers. But right now, @xedaxip791 could reproduce it in 0002241

Hi Derick, I don't know if it gives any value to the investigation, but although I still can't reproduce the problem, I saw the following.
My application has 2 layers, UI + API backend (running in the same docker container, served by the same nginx webserver container). If I call a UI page, which has no interaction to the API layer, enabling a breakpoint works fine. However if I put a breakpoint on the API module, it crashes most of the time. I can break on the UI layer without problem, but it will crash the PHP-FPM workers which are supposed to serve the API call(s).
Of course, if I remove/disable all the breakpoints, the request can go through without crash.

Marking this as "duplicate" of 0002252, as that has a reproduce case that I can reproduce with.