MantisBT - Issues

0002292: Apache2 mod_php exit signal Segmentation fault (11) with Xdebug enabled

Sat, 05 Oct 2024 11:36:01 +0000

Hello, I'm a developer on the phpIPAM project and have encountered a bug using xdebug to test and develop the code.

I am experiencing Segmentation faults with the Xdebug module enabled.

I'm aware you would prefer a minimal php script to reproduce but the process to reproduce is complex. The code spawns a number of threads to ping the subnet, sends the data to the main process via IPC and then iterates over the results using NET/DNS2 to resolve DNS names of discovered hosts.

Is there a way of obtaining additional debugging info from this Apache2 environment?

0002291: function tracing doesn't work on Windows 10 with Nginx 1.9.4 and PHP 8.3.12

Fri, 04 Oct 2024 18:56:53 +0000

When adding xdebug_start_trace() and xdebug_stop_trace() to a function I want to trace, no trace file is generated.

0002290: Process crash when used with php-cgi.exe

Fri, 04 Oct 2024 17:05:25 +0000

Environment:
Windows 11
IIS
Fast-CGI
PHP 8.1.30
Xdebug 3.3.2
Software: Symfony 5.4
Configuration: xdebug.mode=debug

The php-cgi process crashes with this information in the event log:
AppName php-cgi.exe
AppVersion 8.1.30.0
AppTimeStamp 66f5ceef
ModuleName php_xdebug.dll
ModuleVersion 8.1.27.0
ModuleTimeStamp 66ffe7b0
ExceptionCode c0000005
FaultingOffset 000000000001cc3c
ProcessId 0x2794
ProcessCreationTime 0x1db165ea4785bf1
AppPath c:\tools\php81\php-cgi.exe
ModulePath c:\tools\php81\ext\php_xdebug.dll
IntegratorReportId 0340253b-e616-4076-ab92-a3b2d7c25fe8
PackageFullName

I setup debug symbols and compiled xdebug myself to get a pdb file.
The stacktrace to the exception is:

[Inline Frame] php_xdebug.dll!zend_string_equal_content(_zend_string *) Line 357 C
[Inline Frame] php_xdebug.dll!zend_string_equals(_zend_string * s1, _zend_string *) Line 362 C
> php_xdebug.dll!mark_fse_as_having_line_breakpoints(_function_stack_entry * fse) Line 573 C
[Inline Frame] php_xdebug.dll!handle_breakpoints(_function_stack_entry *) Line 591 C
php_xdebug.dll!xdebug_debugger_handle_breakpoints(_function_stack_entry * fse, int breakpoint_type, _zval_struct * return_value) Line 623 C
[Inline Frame] php_xdebug.dll!xdebug_execute_internal_end(_zend_execute_data *) Line 1004 C
php_xdebug.dll!xdebug_execute_internal(_zend_execute_data * current_execute_data, _zval_struct * return_value) Line 1028 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 1997 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!zend_generator_resume(_zend_generator * orig_generator) Line 756 C
php8.dll!zend_fe_fetch_object_helper_SPEC(_zend_execute_data * execute_data) Line 2766 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!zend_generator_resume(_zend_generator * orig_generator) Line 756 C
php8.dll!zend_generator_ensure_initialized(_zend_generator * generator) Line 809 C
php8.dll!zend_generator_rewind(_zend_generator * generator) Line 818 C
php8.dll!zend_fe_reset_iterator(_zval_struct * array_ptr, int by_ref, const _zend_op * opline, _zend_execute_data * execute_data) Line 4876 C
php8.dll!ZEND_FE_RESET_R_SPEC_VAR_HANDLER(_zend_execute_data * execute_data) Line 21815 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 2010 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!ZEND_INCLUDE_OR_EVAL_SPEC_OBSERVER_HANDLER(_zend_execute_data * execute_data) Line 4988 C
php8.dll!execute_ex(_zend_execute_data * ex) Line 55622 C
php8.dll!zend_execute(_zend_op_array * op_array, _zval_struct * return_value) Line 60190 C
php8.dll!zend_execute_scripts(int type, _zval_struct * retval, int file_count, ...) Line 1858 C
php8.dll!php_execute_script(_zend_file_handle * primary_file) Line 2551 C
php-cgi.exe!main(int argc, char * * argv) Line 2564 C

It seems the executed_filename variable contains an invalid value, see the attached screenshot of Visual Studio.

0002287: zend_mm_heap corrupted in develop mode

Fri, 04 Oct 2024 14:33:02 +0000

Reflecting a class containing new php 8.4 features (property hooks / asymmetric-visibility) with `xdebug.mode = develop` leads to

zend_mm_heap corrupted
Abort trap: 6

0002288: PHP 8.4.0RC1 Zend engine version vs XDebug 3.4.0alpha1

Fri, 04 Oct 2024 14:31:31 +0000

When used with PHP 8.4.0RC1, Xdebug reports the following:
Xdebug requires Zend Engine API version 420230831.
The Zend Engine API version 420240924 which is installed, is newer.
Contact Derick Rethans at https://xdebug.org/docs/faq#api for a later version of Xdebug.

In https://xdebug.org/announcements/2024-05-31 it says that Xdebug 3.4.0alpha1 is a preliminary release with PHP 8.4 support, but it is not possible to test it as for now.

0002289: Cant not access an array's keys

Tue, 01 Oct 2024 07:40:32 +0000

I want to access the $_FILES array. When I watch it with just $_FILES it shows it exists and you can see whats inside. However, when I type $_FILES['card_image'] it shows can not get property, even though it does and I can see it if I expand the $_FILES array. To fix this I assigned another variable to $_FILES and tried to access 'card_image' through it and guess what it worked. Why is this happening?

0002286: Changing xdebug parameters in PHP Pool changes parameters values but has no effect on affected Xdebug Features

Tue, 03 Sep 2024 20:01:49 +0000

Changing xdebug parameters in PHP Pool configuration files changes the parameters value but does not change Xdebug features afected.

What you expected to happen.

I configured 'xdebug.mode=off' in /etc/php/8.2/fpm/conf.d/20-xdebug.ini
to default no debugging and reduce overhead and then changed xdebug.mode from 'off' to 'debug' for a specific website through 'PHP Pool' configuration file and expected the 'Step Debugger' feature to toggle from disabled to enabled.

What happened instead.

xdebug_info() shows the value of xdebug.mode changed to 'debug' but the 'Step Debugger' remains disabled.

If I swith xdebug.mode to 'debug' in the /etc/php/8.2/fpm/conf.d/20-xdebug.ini file the 'Step Debugger' gets enabled.

XDEBUG Version 3.3.2
PHP Version 8.1.29

root@srv1:/# php -v
PHP 8.1.29 (cli) (built: Jun 6 2024 16:53:25) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.29, Copyright (c) Zend Technologies
with Zend OPcache v8.1.29, Copyright (c), by Zend Technologies
with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans

OS Ubuntu 22.04.4 LTS

My question is if I should be able to make xdebug.ini changes through PHP Pool Configuration files and expect XDebug Features to change accordingly or must I make changes only in the main PHP XDEBUG configuration file that applies to all websites in server using the specific version of PHP.

0002283: SoapClient usage causes segfault with codecoverage

Sun, 01 Sep 2024 18:45:06 +0000

using the soapclient like this:

// we fake the soap client to return our prerecorded xml response and have it decoded via the SoapClient
$client = new class ( __DIR__ . '/StationList.wsdl', ['trace' => true]) extends SoapClient {
public function __doRequest(string $request, string $location, string $action, int $version, bool $oneWay = false): string
{
return \file_get_contents(__DIR__ . '/Result.xml') ?: throw new RuntimeException('missing PointListRequestResult');
}
};

$client->getTheStationListFull();

will cause a segfault, see provided github repository for a small reproducer.

(gdb) bt
#0 call_end_observers (return_value=0x0, execute_data=0x5574df430000) at ./Zend/zend_observer.c:265
#1 zend_observer_fcall_end_all () at ./Zend/zend_observer.c:293
0000002 0x00005574eae024d9 in php_request_shutdown (dummy=dummy@entry=0x0) at ./main/main.c:1849
0000003 0x00005574eaf59ace in do_cli (argc=3, argv=0x5574f7a43520) at ./sapi/cli/php_cli.c:1136
0000004 0x00005574eac959c6 in main (argc=3, argv=0x5574f7a43520) at ./sapi/cli/php_cli.c:1340

full backtrace here: https://github.com/verfriemelt-dot-org/xdebug-soap-segfault/blob/main/backtrace.log

0002252: Running phpunit in coverage triggers segfault in xdebug_branch_info_mark_reached

Fri, 30 Aug 2024 09:29:34 +0000

When using php 8.2.17 and xdebug 3.3.1 on phpunit 9 coverage test triggers a segfault

0002285: php 8.3.10 oops @ object cache flush if Xdebug enabled

Tue, 13 Aug 2024 18:54:13 +0000

on
```
distro
Name: Fedora Linux 40 (Forty)
Version: 40
Codename:

uname -rm
6.10.3-200.fc40.x86_64 x86_64
```

with
```
rpm -qa | grep -E "php-common|php-fpm|php-redis"
php-common-8.3.10-1.fc40.remi.x86_64
php-fpm-8.3.10-1.fc40.remi.x86_64
php-pecl-redis6-6.1.0~RC1-1.fc40.remi.8.3.x86_64

php -v
PHP 8.3.10 (cli) (built: Jul 30 2024 13:44:37) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.3.10, Copyright (c) Zend Technologies
with Zend OPcache v8.3.10, Copyright (c), by Zend Technologies
with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans

php-fpm -v
PHP 8.3.10 (fpm-fcgi) (built: Jul 30 2024 13:44:37)
Copyright (c) The PHP Group
Zend Engine v4.3.10, Copyright (c) Zend Technologies
with Zend OPcache v8.3.10, Copyright (c), by Zend Technologies
with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans
```

in an app instance (Wordpress 6.6.1), exec of an Object Cache flush results in
```
Aug 13 11:44:49 test kernel: php-fpm[9241]: segfault at 23e00000070 ip 00005563d19807ab sp 00007ffddf340250 error 4 in php-fpm[3037ab,5563d16ab000+33c000] likely on CPU 14 (core 6, socket 0)
Aug 13 11:44:49 test kernel: Code: e8 01 00 00 48 89 45 c8 48 85 db 0f 84 9b 00 00 00 4c 8d 35 eb 76 1d 00 0f 1f 80 00 00 00 00 49 89 9d e8 01 00 00 48 8b 53 18 <48> 8b 42 38 a8 01 74 12 48 8d 0d 06 21 1d 00 48 8b 89 e0 01 00 00
```

@ core dump
```
gdb /usr/sbin/php-fpm /var/lib/systemd/coredump/core.9241
(gdb) set pagination off
(gdb) bt full

(gdb) bt full
#0 call_end_observers (execute_data=0x5563cd6db840, return_value=0x0)
at /usr/src/debug/php-8.3.10-1.fc40.remi.x86_64/Zend/zend_observer.c:265
func = 0x23e00000038
handler =
possible_handlers_end =
#1 zend_observer_fcall_end_all () at /usr/src/debug/php-8.3.10-1.fc40.remi.x86_64/Zend/zend_observer.c:293
execute_data = 0x5563cd6db840
original_execute_data = 0x0
0000002 0x00005563d1866850 in php_request_shutdown (dummy=dummy@entry=0x0)
at /usr/src/debug/php-8.3.10-1.fc40.remi.x86_64/main/main.c:1862
report_memleaks = true
0000003 0x00005563d16f517e in main (argc=, argv=)
at /usr/src/debug/php-8.3.10-1.fc40.remi.x86_64/sapi/fpm/fpm/fpm_main.c:1970
primary_script =
__orig_bailout =
__bailout = {{__jmpbuf = {10, -6812356180845851385, 6, 93887207390336, 0, 93887208458776,
-6812356180952806137, -843938314294326009}, __mask_was_saved = 0, __saved_mask = {__val = {
140660866771648, 63, 18446744073709551072, 0, 4222461064, 140728348183984, 140660865462146, 0,
140660865924268, 93887539638944, 1024, 0, 0, 140728348184192, 140660865304512, 22}}}}
exit_status =
cgi = 0
c =
use_extended_info =
file_handle = {handle = {fp = 0x0, stream = {handle = 0x0, isatty = 0, reader = 0x0, fsizer = 0x0,
closer = 0x0}}, filename = 0x0, opened_path = 0x0, type = 0 '\000', primary_script = true,
in_list = false, buf = 0x0, len = 0}
orig_optind = 1
orig_optarg = 0x0
ini_builder = {value = 0x0, length = 0}
max_requests = 200
requests =
fcgi_fd =
request = 0x5563e5b3aa80
fpm_config =
fpm_prefix =
fpm_pid =
test_conf = 0
force_daemon =
force_stderr =
php_information =
php_allow_to_run_as_root =
__func__ = "main"
ret =
__orig_bailout =
__bailout =
__str =
(gdb)
```

if edit -> DISABLE Xdebug
```
/usr/local/etc/php8/conf.d/xdebug.ini
- xdebug.mode = on
+ xdebug.mode = off
```
, and restart, it *does not* segfault on exec of the in-WP ObjectCache flush (in 0000017:0000010 attempts, so far)

turn it back on, and immediately segfaults on the flush, as above.

not sure, yet, how to 'simply' reproduce this from cli ...

0001964: WSL UNC paths don't have needed prefix

Mon, 12 Aug 2024 13:58:02 +0000

I just ran into an issue where Xdebug is presenting a UNC path in such way I cannot map it back to original.

I executed a script from an UNC path \\WSL$\UBUNTU\home\zobo\php\test1.php

Looking at phpinfo() output, php is OK with it:

```
...
$_SERVER['PHP_SELF'] => \\wsl$\Ubuntu\home\zobo\php\test1.php
$_SERVER['SCRIPT_NAME'] => \\wsl$\Ubuntu\home\zobo\php\test1.php
$_SERVER['SCRIPT_FILENAME'] => \\wsl$\Ubuntu\home\zobo\php\test1.php
$_SERVER['PATH_TRANSLATED'] => \\wsl$\Ubuntu\home\zobo\php\test1.php
...
$_SERVER['argv'] => Array
(
[0] => \\wsl$\Ubuntu\home\zobo\php\test1.php
)
...
```

However Xdebug presents the files as:
```
[50452] [Step Debug] -> https://xdebug.org/dbgp/xdebug" fileuri="file://WSL%24/UBUNTU/home/zobo/php/test1.php" language="PHP" xdebug:language_version="8.0.4RC1" protocol_version="1.0" appid="50452">https://xdebug.org]]>
```

Also true for stack:
```
[50452] [Step Debug] <- stack_get -i 4
[50452] [Step Debug] -> https://xdebug.org/dbgp/xdebug" command="stack_get" transaction_id="4">file://WSL%24/UBUNTU/home/zobo/php/test1.php" lineno="3">
```

I am not sure if this is true in case of network mapped UNC paths, but I have a strong suspicion it is. See: https://github.com/xdebug/vscode-php-debug/issues/546

In case it's a normal "windows path" the url becomes `file:///C:/...`. So in theory I could infer that it should be prefixed with `\\`, but I'd rather not...

Was this already encountered?

0002268: xDebug 3.3.1 or 3.3.2 crash on NGINX+Docker and PHP8.1.27

Thu, 08 Aug 2024 11:17:58 +0000

The error I get when xDebug is

2024/03/20 14:43:47 [error] 4053#0: *3184 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.3, server: testdomain.dev, request: "GET /SmartSpending HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:", host: "site1.testdomain.dev", referrer: "https://site1.testdomain.dev/SmartSpending"

It seems that xDebug resets the connection each time I enable the web plugin and try to test a breakpoint. However on my site2. it works perfectly.

Attached logs.

Local env conf:

centos7/alma-linux on the docker container
PHP 8.1.27 with php-fpm 8.1.27, nginx and xdebug 3.3.1

0002257: xdebug is base64 encoding long strings, resulting in code fault

Wed, 07 Aug 2024 19:37:17 +0000

I have a very long string in hexadecimal format, convert it with `hex2bin` at this point Xdebug on Sublime Text is showing me the variable base64 encoded for some reason, if I `echo` the variable it prints correctly, if I try to `$r=json_decode($r, true);` it returns null, because it assumed the variable is really its base64 encoded representation.

0002276: Custom error handler return true will stop Exception handlers from breaking - returning false will write to PHP error log though

Wed, 07 Aug 2024 15:22:18 +0000

When using a custom error handler, I can `return true;` to avoid it bubbling up to PHP's native error handler (or any system defined handlers for that matter)*
This will obviously prevent xdebug breaking on the exception (assuming there is a PHP Exception breakpoint set up)

Therefore, one must return false to make xdebug work - that's fine.
The problem though is, that this (xdebug) will then bubble it up to the native PHP error handler and the error ends up in the PHP error log specified.

There needs to be a way to tell xdebug to NOT bubble up the error to PHP's native error handler, to prevent errors ending up in the error log.

e.g. xdebug_disable_next_error_bubble(); to skip bubbling of the next or xdebug_disable_error_bubble(); to disable it altogether; or possible a ini setting?

*see https://www.php.net/manual/en/function.set-error-handler.php#:~:text=It%20is%20important%20to%20remember%20that%20the%20standard%20PHP%20error%20handler%20is%20completely%20bypassed%20for%20the%20error%20types%20specified%20by%20error_levels%20unless%20the%20callback%20function%20returns%20false

0002275: xdebug.start_with_request=no does not allow starting step debugging with xdebug_break() despite docs saying so

Wed, 07 Aug 2024 14:20:55 +0000

https://xdebug.org/docs/all_settings#start_with_request

>no
>The functionality does not get activated when the request starts.
>You can still start ... Step Debugging with xdebug_break(),

However, in practice this does not work (but only works when it's set to e.g. "trigger")

0002259: Does not stop on breakpoints when files are located on a UNC path drive

Wed, 07 Aug 2024 13:49:35 +0000

When the files to be debugged are located on an UNC drive like \\NAS\\xyz, instead of a local drive, the breakpoints are never hit and they are marked as unverified. Also using a network attached drive does not help, because the IIS file location configuration is set to the UNC drive.

0002161: Breakpoints not updated when process is running

Wed, 07 Aug 2024 13:41:58 +0000

When a PHP is process is already running and you add a new breakpoint, it will never be triggered unless a script is restarted.

With the rise of popularity of Swoole, RoadRunner, AmPHP and related tools like Laravel Octane, this becomes increasingly more of a problem because debugging gets much harder. In case of Swoole, they've recently added support for XDebug, but it's still hard to actually make use of it because of having to constantly restart the server to make it reload the breakpoints.

There are workarounds for that, but all are suboptimal:
- you can either run php-fpm alongside Swoole solely for debugging (which makes it unnecessarily complex and sometimes doesn't allow reproducing the problem the same way as in Swoole)
- or you can reload Swoole every time you add a breakpoint, which kills the developer experience

Are there any possible workarounds XDebug can implement to address this issue?

0002265: Refletion consumes an exorbitating amount of resources if var_display_max_children and similars are unlimited or very high

Wed, 07 Aug 2024 13:39:54 +0000

Reflection is used, for instance, on DI containers with autowiring.

For the DI Container to autowire, it needs to call ReflectionMethod($class, '__construct') to get an instance of the constructor.

This call becomes extremely expensive if Xdebug is active on "develop" mode and "var_display_max_children" is unlimited or very high, as per screenshot attached.

0002256: general protection fault leading Apache to report 503

Wed, 07 Aug 2024 13:38:59 +0000

Setting a breakpoint on my chrome leads to a GPF, no idea what I should do to try and deal with this.

0002222: Xdebug holds a reference to objects in the stack trace of a caught exception

Wed, 07 Aug 2024 13:34:47 +0000

I think relating to the 3.3.0 release which fixed some issues with exception.

I am now seeing in a Drupal context that objects are not getting their destructor called sometimes when they should. With Xdebug disabled it calls them normally at the end of the method that created them when their variable goes out of scope.

I think it's related to exceptions being rethrown in some cases perhaps it is "capturing" a reference in a stack and then preventing it from destructing.

0002284: PHP 8.2 does not work with ioncube and xdebug on Windows

Wed, 07 Aug 2024 10:45:45 +0000

524 / 5.000
If a PHP script that is encrypted is executed with xdebug active, the following error occurs

Error: Secure connection failed
An error occurred while connecting to localhost. PR_CONNECT_RESET_ERROR
Error code: PR_CONNECT_RESET_ERROR

The website cannot be displayed because the authenticity of the received data could not be verified.
Please contact the owner of the website to inform him of this problem.

Scrpt runs with xdebug or ioncube alone.

0002282: XDebug crashes with XDEBUG_SESSION cookie

Tue, 23 Jul 2024 09:22:05 +0000

Like I said in previous issues, there seem to be some issue with debugging with Xdebug when triggering it using a `XDEBUG_SESSION` cookie. When the cookie is set and set with the request Nginx returns:

502 Bad Gateway
nginx/1.25.2

After some checking it looks like it only happens with "web" requests as calling `php` in CLI with xdebug arguments properly triggers it and step debugging is working without crash.

So it appears that it may be a problem with Nginx/php-cgi.exe. Unfortunately I don't have much experience with debugging C errors, so I would gladly listen how to create some debug logs for it.

0002271: Segmentation fault whenever php8.1-xdebug extension is enabled

Thu, 18 Jul 2024 13:36:59 +0000

We're getting segmentation faults from php-fpm whenever the php8.1-xdebug extension is enabled. This issue occurs consistently within our docker container built on the arm64v8/ubuntu base image. The docker engine is running on a macOS Ventura host. We get the following stack trace from the core dump:

Reading symbols from /usr/sbin/php-fpm8.1...
(No debugging symbols found in /usr/sbin/php-fpm8.1)
[New LWP 781]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `php-fpm: pool www '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000ffffa84f9190 in zend_string_equal_content (s2=0x6c70736964207463, s1=0xffffa8257de0) at /usr/include/php/20210902/Zend/zend_string.h:357

warning: Source file is more recent than executable.
357 return ZSTR_LEN(s1) == ZSTR_LEN(s2) && zend_string_equal_val(s1, s2);

(gdb) bt
#0 0x0000ffffa84f9190 in zend_string_equal_content (s2=0x6c70736964207463, s1=0xffffa8257de0) at /usr/include/php/20210902/Zend/zend_string.h:357
#1 zend_string_equals (s2=0x6c70736964207463, s1=0xffffa8257de0) at /usr/include/php/20210902/Zend/zend_string.h:362
0000002 mark_fse_as_having_line_breakpoints (fse=0xaaaab8d88e70) at ./build-8.1/src/debugger/debugger.c:573
0000003 handle_breakpoints (return_value=0xffffe10e1c08, breakpoint_type=8, fse=0xaaaab8d88e70) at ./build-8.1/src/debugger/debugger.c:591
0000004 xdebug_debugger_handle_breakpoints (fse=fse@entry=0xaaaab8d88e70, breakpoint_type=breakpoint_type@entry=8, return_value=return_value@entry=0xffffe10e1c08) at ./build-8.1/src/debugger/debugger.c:623
0000005 0x0000ffffa84e1e38 in xdebug_execute_internal_end (current_execute_data=, return_value=0xffffe10e1c08) at ./build-8.1/src/base/base.c:1004
0000006 xdebug_execute_internal (current_execute_data=, return_value=0xffffe10e1c08) at ./build-8.1/src/base/base.c:1028
0000007 0x0000aaaaaeab38e8 in ?? ()
0000008 0x0000aaaaaecfaa68 in execute_ex ()

0002277: Segfault Sigsegv for throw in callable/closure

Thu, 18 Jul 2024 13:36:28 +0000

In search I found https://bugs.xdebug.org/view.php?id=2222 which seems to be tangentially related, however in my case there is no `__desctruct` method in the object, as well as that xdebug crashes in the middle of the application, which is worse than that issue.

> WARNING: [pool www] child 1457777 exited on signal 11 (SIGSEGV - core dumped)

xdebug 3.3.2
PHP 8.3.8 (php-fpm sapi)

`xdebug.mode=debug,develop`

- removing "develop" fixes the problem
- this issue happens even if no debug session is active and no develop functions have been called either
- memory limit is 4096M, php memory_get_usage() reports memory consumption of between 40-180M (depending on how the issue is reproduced) in the line directly before it segfaults
- the code that segfaults is a `throw` that is caught with a try/catch
- the issue doesn't happen on the first occurrence/invokation of this throw, but after x calls to the throw it suddenly segfaults (might be another cause, just an observation)
- it seems that this is related to throw inside a closure and/or method invoked on a dynamic object (e.g. new $foo()), but again, this is just an observation
- there is no loop/recursion

0002253: xDebug 3.3.1 crash on NGINX+Docker and PHP8.1.27

Thu, 18 Jul 2024 13:35:47 +0000

The error I get when xDebug is

2024/03/20 14:43:47 [error] 4053#0: *3184 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.3, server: testdomain.dev, request: "GET /SmartSpending HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:", host: "site1.testdomain.dev", referrer: "https://site1.testdomain.dev/SmartSpending"

It seems that xDebug resets the connection each time I enable the web plugin and try to test a breakpoint. However on my site2. it works perfectly.

Attached logs.

Local env conf:

centos7 on docker container
PHP 8.1.27 with php-fpm 8.1.27, nginx and xdebug 3.3.1