Hi,

I have had a look at the differences between 3.1.1 and 3.1.2 in the source code, but nothing specific jumped out that could hint at an extra cause for a segfault. I'm afraid I am going to need some more information.

1. Preferably a backtrace, as is explained under "Generating backtrace, without compiler, on Windows" at https://bugs.php.net/bugs-generating-backtrace-win32.php — this provides a hint to me where the crash could occur. Installing the debug pack as mentioned earlier in that file, would be a great help too. Because your PHP version is no longer supported by the PHP project, you can find the php-debug-pack that you need in https://windows.php.net/downloads/releases/archives/.
2. To narrow down where in your code this occurs, configure xdebug.mode=develop,trace and set xdebug.start_with_request=yes, and perhaps xdebug.output_dir=C:\Temp (or something more suitable), and then run the tests. This should create a (big) trace file in that directory, up to the point where it crashes. You might get lucky that the actual call is there, but otherwise it should be the next one.

You might also want to check whether opcache is enabled, and whether removing that changes anything.

cheers,
Derick

Sorry it took me some time to come back to this. I don't have the faintest what this could be, but I am making a reasonable guess that some sequence does make this happen. It does seem to happen when an exception is thrown, which fetches a backtrace :

php7ts!zend_= fetch_debug_backtrace+138 [c:\php-snap-build\php73\vc15\x64\php-7.3.3= 3-ts\zend\zend_builtin_functions.c @ 2489 + 5]php7ts!zend= _default_exception_new_ex+95 [c:\php-snap-build\php73\vc15\x64\php-7.= 3.33-ts\zend\zend_exceptions.c @ 222]

But this crash does not occur in Xdebug at all, but rather just in PHP.

Often when crashes happen at seemingly random locations, I would run my scripts with Zend's Memory Manager disabled, as it sometimes hides real issues. You can do that by exporting the USE_ZEND_ALLOC=0 environment variable. I believe on Windows that is done with set USE_ZEND_ALLOC=0. And with this set, then run the scripts again as before.

Hi,

did you manage to run the new test with set USE_ZEND_ALLOC=0 as I asked in the previous note?

cheers,
Derick

I can't reproduce this, and the original reporter did not provide the requested information. If this is still an issue, please reopen this issue, or file a new one.

Sorry, Derick, for not getting backa t you with the requested information.

Today, I ran the affected test suite with various 3.1.x versions of Xdebug including the recently released 3.1.6, again.
It seems the new release fixed the issue, as I could run through the whole test suite with it.

So, up until 3.1.1 it worked, 3.1.2 up including 3.1.5 are affeced of this bug and 3.1.6 seems to fix it.

Hi Derick,

After some hours of debugging, I found the culprit:

CakePHP 3.x App Template contains calls to xdebug_print_function_stack

• Error 4xx HTML page template
  https://github.com/cakephp/app/blob/947a954ea80294ac9e1632e4a9c1ba9af254fd76/src/Template/Error/error400.ctp#L27-L29
• Error 5xx HTML page template
  https://github.com/cakephp/app/blob/947a954ea80294ac9e1632e4a9c1ba9af254fd76/src/Template/Error/error500.ctp#L32-L34

CakePHP 4.x App Template does not contain any call to xdebug_print_function_stack (anymore)

• Full code search
  https://github.com/cakephp/app/search?q=xdebug_print_function_stack
• Error 4xx HTML page template
  https://github.com/cakephp/app/blob/b8621fa75e9a03a8250c0dc53b4cdb1375ac2628/templates/Error/error400.php
• Error 5xx HTML page template
  https://github.com/cakephp/app/blob/b8621fa75e9a03a8250c0dc53b4cdb1375ac2628/templates/Error/error500.php
• Removed in https://github.com/cakephp/app/commit/c3fe08a7e2e2bd79c3762f9db3687ec43ab108d7

xdebug_print_function_stack( string $message = "user triggered", int $options = 0 ) : void #
https://xdebug.org/docs/develop#xdebug_print_function_stack

It seems this function is buggy in some setups or call orders.

I don't have the faintest what this could be, but I am making a reasonable guess that some sequence does make this happen. It does seem to happen when an exception is thrown, which fetches a backtrace :

You were right on this.

For us, the workaround will be to disable this function call in our CakePHP 3.x applications and for CakePHP 4.x we will remove it as the CakePHP devs have done so.

Thank you & have some relaxing holidays with some nice Whisky.
Marc