MantisBT - Issues

0002398: Add EOF marker/stanza to native path file mapper

Tue, 12 May 2026 16:11:18 +0000

Sometimes, you need to say from line to the end of file, and the only way to do that now is to use 6-99999 or a similarly high value. That's not nice.

This ticket comes forth out of https://github.com/twigphp/Twig/pull/4733#discussion_r2689950107

0002406: Tests failing on armhf with PHP 8.5

Mon, 11 May 2026 08:27:20 +0000

Running the upstream tests in Ubuntu, using PHP 8.5 results in a fail.
See logs in: https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-resolute/resolute/armhf/x/xdebug/20260224_020114_37526@/log.gz

In the logs:

=====================================================================
520s FAILED TEST SUMMARY
520s ---------------------------------------------------------------------
520s Test for bug 0001343: Wrong values of numerical keys outside 32bit range [tests/develop/bug01343-32bit.phpt]
520s =====================================================================

Does not say much, but looking at other PHP 8.5 armhf failures, it may be related to a warning about not being able to cast floats outside of the 32 bit range (exactly what the test is about) to int. This warning was not there in PHP8.4, but it's always there in PHP 8.5.

0002396: xdebug eval can't define anonymous functions

Sun, 10 May 2026 17:41:36 +0000

it used to be able to do this. It was an invaluable convenience to our whole company for testing our code.

0002403: Better support of worker mode

Sun, 10 May 2026 16:15:46 +0000

The current implementation is not ideal to debug worker mode.
You need to:
1. add your breakpoint before starting the worker
2. call xdebug_connect_to_client (and that's included in symfony runtime) but it bypasses the xdebug.start_with_request=trigger configuration

It's possible to offer a better support of worker mode by hooking with frankenphp and enable / disable profiling when needed.

0002413: Suggestion: Develop mode in terminal

Sun, 10 May 2026 16:10:45 +0000

Suggestion to not display html tags in develop mode in terminal use

0002244: xDebug 3.3.x crashes Apache on Ubuntu 22.04 via WSL2; PHP 8.1, seeking resolution.

Wed, 06 May 2026 15:31:24 +0000

Hello xDebug Team,

We've encountered recent issues with version 3.3.x. When enabling the PHP debug extension via the ini file, our PHP crashes (our custom hostname becomes inaccessible, though localhost remains accessible) with Apache, despite the CLI version working fine. Versions equal to or before 3.2.x function without any problems; it's only the latest xDebug version causing issues.

Though we don't have extensive logs, one of our developers encountered segfault errors when enabling the latest xDebug version.

Our development environment consists of:

Platform: Windows Subsystem for Linux (WSL2)
OS: Ubuntu 22.04
Web Server: Apache (using supervisor to run apache and mysql services)
PHP Version: 8.1
Other enabled PHP extensions on our server include:

ionCube PHP Loader v13.0.2
Zend OPcache v8.1.27
We'd appreciate any assistance you can provide in resolving this matter.

0002420: Introduce separate flags for branch coverage and path coverage collection

Wed, 29 Apr 2026 09:43:28 +0000

Currently, Xdebug provides a single flag, XDEBUG_CC_BRANCH_CHECK, which activates both branch coverage and path coverage collection simultaneously. I'd like to propose splitting this into two independent flags so that branch coverage and path coverage can be activated separately.

The current design only supports two scenarios:

1. Line coverage only (no flag)
2. Line coverage + branch coverage + path coverage (XDEBUG_CC_BRANCH_CHECK)

There is no way to enable branch coverage without also enabling path coverage. My assumption is that collecting branch coverage information alone is less resource-intensive than collecting both branch coverage and path coverage. Users who only need branch coverage currently have to pay the additional cost of path coverage collection, even if they do not make use of that data.

Splitting the flag would enable three scenarios:

1. Line coverage only
2. Line coverage + branch coverage
3. Line coverage + branch coverage + path coverage

And technically also "line coverage + path coverage", but I do not see how this would be useful in practice.

I would like to propose two new flags:

- XDEBUG_CC_BRANCH_COVERAGE to activate branch coverage
- XDEBUG_CC_PATH_COVERAGE to activate path coverage

I am not sure whether or not XDEBUG_CC_PATH_COVERAGE should also activate branch coverage.
I am aware that the "_CC" infix and the "_COVERAGE" suffix carry redundant information, so the names are not ideal. I have not come up with better names yet, sorry.

In a perfect world, the existing XDEBUG_CC_BRANCH_CHECK flag would be redefined to mean "activate branch coverage only". However, this would be a backward-compatibility break for existing users who rely on its current behaviour of also activating path coverage. To avoid that, I propose the deprecation of XDEBUG_CC_BRANCH_CHECK and the granular / separate flags shown above.

0002419: Line coverage does not report ternary branch lines when ternary is inside an array literal

Fri, 24 Apr 2026 09:36:14 +0000

When a multiline ternary operator is used as a value inside an array literal, xdebug_get_code_coverage() does not report coverage data for the lines containing the true and false branch expressions. The same ternary in a simple variable assignment context reports both branch lines correctly.

This affects php-code-coverage (used by PHPUnit). When a ternary operator spans multiple lines inside an array literal, the branch expression lines do not appear in coverage reports at all. They are neither green (executed) nor red (not executed). They are simply not treated as executable lines.

Reported in https://github.com/sebastianbergmann/php-code-coverage/issues/1029

0002407: Performance issues with 3.5.1 vs 3.4

Mon, 23 Mar 2026 19:13:14 +0000

I updated my PHP and Xdebug today.
Some performance testing scripts i have suddenly saw issues.
Saw the other tickets concerning performance issues and can say 3.5.1 is better compared to 3.5.0 but not to earlier versions.

CPU: AMD 5700G
All of this was done on PHP 8.3.30 since Xdebug 3.4.7 was not available for PHP 8.5.x.

0002402: Error in xdebug 3.5 with PHP 8.5 when executing code with the pipe operator

Mon, 23 Mar 2026 15:59:06 +0000

When trying to execute code with the new piper operator, PHP is unable to return the output and reports the error: zend_mn_heap_corrupted (this in the CLI, in the browser it reports error 500)

By disabling xdebug in php.ini, PHP can correctly interpret the code snippets containing the pipe operator.
Initially I thought it was the Xdebug version, I changed it to the latest version, which is 3.5, and PHP to 8.5.1 and not even with that (I noticed that Xdebug only supports version 8.5.0).

And when writing other codes, PHP with Xdebug enabled runs normally.

0002394: Can't create control Named Pipe

Mon, 23 Mar 2026 15:36:12 +0000

I'm always getting:

[25784] Log opened at 2025-12-31 14:45:05.172564
[25784] [Config] WARN: Can't create control Named Pipe (0x0)
[25784] Log closed at 2025-12-31 14:45:05.173333

As such, no stop by Xdebug at breakpoint.

0002412: No warning shown before logging out while writing a post.

Sat, 21 Mar 2026 18:36:42 +0000

If a user is writing a post and accidentally clicks logout, the system logs out immediately without any confirmation. This results in loss of typed content.

0002391: Code Coverage times out on random tests

Tue, 24 Feb 2026 14:25:27 +0000

We accidentally installed 3.50-dev and then our code coverage started failing. I listed as always reproducible because if we run our entire test suite, it happens every time. However, the particular test that times out varies.

Step 3/3: PHPUnit (Command Line)
19:24:05 Starting: D:\TeamCityBuildAgent\temp\agentTmp\custom_script1165008140808374324.cmd
19:24:05 in directory: D:\TeamCityBuildAgent\work\9e132eb6cf93e5a8
19:26:58 PHPUnit 12.4.1 by Sebastian Bergmann and contributors.
19:26:58
19:26:58 Runtime: PHP 8.4.14 with Xdebug 3.5.0-dev
19:26:58 Configuration: D:\TeamCityBuildAgent\work\9e132eb6cf93e5a8\phpunit\phpunit-coverage.xml
19:26:58
19:27:03 D:\TeamCityBuildAgent\work\9e132eb6cf93e5a8\phpunit\phpunit-coverage.xml
19:29:37
19:29:37 Fatal error: Maximum execution time of 120 seconds exceeded in D:\TeamCityBuildAgent\work\9e132eb6cf93e5a8\vendor\phpmailer\phpmailer\src\PHPMailer.php on line 895
19:29:37 Maximum execution time of 120 seconds exceeded

19:29:37
19:29:37
19:29:37
19:29:37

#	File:Line	Function
1		classes\ErrorHandling::errorHandlerShutdown::
2	D:\TeamCityBuildAgent\work\9e132eb6cf93e5a8\vendor\phpmailer\phpmailer\src\PHPMailer.php:895

19:29:37
19:29:37
19:29:37
19:29:37

#	Arguments
1
2

Fatal error: Premature end of PHP process when running classes\Controllers\ETL_StatusTest::test_updateETLsToRunNow_AllStaging.
19:29:37 Process exited with code 255

0002385: Allow IDEKEY/Cloud ID key from php.ini be overridden through XDEBUG_SESSION_START variable if xdebug.start_with_request=yes

Fri, 06 Feb 2026 10:18:35 +0000

In some cases users might want to have a default Cloud ID key configured in php.ini, with xdebug.start_with_request=yes set. This is useful to intercept and debug requests where the XDEBUG_SESSION_START value is missing. Although this works, this stops Xdebug from using the XDEBUG_SESSION_START altogether if one is present, as xdebug.start_with_request=yes short-circuits the checking for this value.

Subsequently, this means that if XDEBUG_SESSION_START is present, it is not looked at, and the Cloud ID key that it might include is not used.

What instead should happen, is that even with xdebug.start_with_request=yes is set, it should use the XDEBUG_SESSION_START value when connecting to the IDE/Xdebug Cloud, and hence override the hard-coded one from php.ini.

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

Tue, 03 Feb 2026 16:31:37 +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.

0002397: Very slow with Xdebug 3.5.0

Tue, 03 Feb 2026 15:37:31 +0000

I've installed Xdebug 3.5.0 with PHP versions 8.5, 8.4, 8.3 and all are very slow compared to Xdebug 3.4.x.

Here is test code.
```
// Start the benchmark
$start_time = microtime(true);

// Code block to benchmark (example: a simple loop)
$iterations = 1000000;
for ($i = 0; $i < $iterations; $i++) {
// Perform some operation, e.g., string concatenation
$result = "Test string" . $i;
}

// Stop the benchmark
$end_time = microtime(true);

// Calculate and display the total time taken in seconds
$total_time = round(($end_time - $start_time), 4);
echo 'Code execution time: ' . $total_time . ' seconds.';
```

With Xdebug 3.4.x, the result will be around 0.12xxx - 0.13xxx seconds.
But with Xdebug 3.5.0 the result go up to 9 seconds+ or more.

Tested with PHP 8.3, 8.4, 8.5 on Windows.

php -v
> PHP 8.5.0 (cli) (built: Nov 18 2025 08:16:50) (NTS Visual C++ 2022 x64)
> Copyright (c) The PHP Group
> Zend Engine v4.5.0, Copyright (c) Zend Technologies
> with Xdebug v3.5.0, Copyright (c) 2002-2025, by Derick Rethans
> with Zend OPcache v8.5.0, Copyright (c), by Zend Technologies

Web server:
Apache/2.4.46 (Win64) OpenSSL/1.1.1i mod_fcgid/2.3.10-dev
Non thread safety.
Compiler: Visual C++ 2022
Architecture: x64

php.ini config:
```
; Xdebug
zend_extension = 'D:/wwwserver-x64/php/xdebug/php_xdebug-3.5.0-8.5-nts-vs17-x86_64.dll'
xdebug.profiler_append = 0
xdebug.start_with_request = trigger
xdebug.mode = develop,profile
xdebug.output_dir = 'D:/my-dev-programs/wwwserver-x64/tmp/xdebug'
xdebug.profiler_output_name = 'cachegrind.out.%p%H%R'
```

Xdebug log:
> [8168] Log opened at 2026-01-14 04:42:56.268240
> [8168] [Config] WARN: Can't create control Named Pipe (0xe7)
> [8168] [Config] INFO: Trigger value for 'XDEBUG_TRIGGER' not found, falling back to 'XDEBUG_PROFILE'
> [8168] [Config] INFO: Trigger value for 'XDEBUG_PROFILE' not found, so not activating
> [8168] Log closed at 2026-01-14 04:43:10.227919

0002390: Exception not caught when iterating over a Generator variable with try-finally

Thu, 22 Jan 2026 16:01:58 +0000

We've noticed unit tests failing after updating to PHP 8.4.15 because an exception was no longer caught when it should have been.
I am not sure what exactly causes the issue, but I've narrowed it down to the minimal reproducer provided below. I was not able to trim it down any further.

I was unable to reproduce the issue with PHP 8.4.14 or with XDebug disabled which leads me to believe that this is a bug in XDebug.

0002401: Error al guardar cambios de nombre de usuario - Botón de guardar no responde

Thu, 22 Jan 2026 16:01:16 +0000

Él no puede guardar las modificaciones realizadas en su nombre de perfil de usuario en la página de "Mi cuenta"

0002400: Invent better way of configuring lots of line-to-line mappings

Thu, 15 Jan 2026 13:01:55 +0000

Right now, for mapping files that concern mapping lines to other lines, as will be common with Templating engines, each file name needs to be re-recorded in each file, such as in:

```
# Path prefixes
remote_prefix: /home/derick/dev/xdebug.cloud/src/cache/compiled_templates/xhtml-updqr0
local_prefix: /home/derick/dev/xdebug.cloud/src/templates

# The mapping table
user-info-823edfe12e38a649355c5172b9d98e0a.php:2-31 = user-info.ezt:1
user-info-823edfe12e38a649355c5172b9d98e0a.php:32-33 = user-info.ezt:2
user-info-823edfe12e38a649355c5172b9d98e0a.php:34-36 = user-info.ezt:3
user-info-823edfe12e38a649355c5172b9d98e0a.php:37 = user-info.ezt:4
user-info-823edfe12e38a649355c5172b9d98e0a.php:38 = user-info.ezt:5
user-info-823edfe12e38a649355c5172b9d98e0a.php:39-40 = user-info.ezt:6
user-info-823edfe12e38a649355c5172b9d98e0a.php:41-46 = user-info.ezt:7
…
user-info-823edfe12e38a649355c5172b9d98e0a.php:301-302 = user-info.ezt:73
user-info-823edfe12e38a649355c5172b9d98e0a.php:303 = user-info.ezt:74-75
```

Instead, it would be much better if you could also do something akin to:

```
remote_prefix: /home/derick/dev/xdebug.cloud/src/cache/compiled_templates/xhtml-updqr0
local_prefix: /home/derick/dev/xdebug.cloud/src/templates

user-info-823edfe12e38a649355c5172b9d98e0a.php = user-info.ezt (@2-31=1;32-33=2;34-36=3,37=4;38=5;39-40=6;41-46=7…)
```

Or a different syntax...

This ticket came forth out of https://github.com/twigphp/Twig/pull/4733#discussion_r2689930741 and the "Future Scope" from the original design document: https://xdebug.org/funding/001-native-path-mapping#future-scope

0002399: Create `xdebug_add_source_map_directory` to dynamically add directories where Xdebug will load path mapping files from

Thu, 15 Jan 2026 12:54:08 +0000

Sometimes, a templating system would like to put mapping files in its own cache/compiled_templates directory, and not necessarily in the `.xdebug` in the root of the project.

Add the `xdebug_add_source_map_directory` function to add and load new files from the specified directory — when called. The function must also look at already existing breakpoints, and rewrite them with the new file/line for this to be effective.

This ticket comes forth out of https://github.com/twigphp/Twig/pull/4733#pullrequestreview-3654648341

0002383: Segmentation fault (8.3) / zend_mm_heap corrupted (8.4)

Wed, 14 Jan 2026 11:04:08 +0000

Currently using XDebug 3.4.7 but this was not a selectable production version.

When running our test suite when using PHP 8.3.20+ or PHP 8.4.6+ with XDebug enabled, in the middle of the PHPUnit test suite it crashes with either Segmentation fault (PHP 8.3) or zend_mm_heap corrupted (PHP 8.4). If I set the environment variable XDEBUG_MODE="off" the issue disappears.

The crash happens both in my local where XDebug is running with mode "develop,debug" and in our pipeline where it's running with "coverage".

0002392: Add option to count how often a line of code was executed using code coverage

Wed, 07 Jan 2026 10:51:18 +0000

Currently, Xdebug's code coverage reporting only indicates whether a line has been executed; it doesn't capture how often it has been executed between xdebug_start_code_coverage() and xdebug_get_code_coverage()/xdebug_stop_code_coverage().

I would like to propose the restoration and enhancement of Xdebug's line-level execution counting capability. This would allow the tracking of how many times each line of code is executed during code coverage analysis, rather than simply marking lines as either executed (1), not executed (0), or not reachable (-1) (when dead code analysis is enabled).

Xdebug previously tracked how often a line was executed. This changed in 2004 (see https://github.com/xdebug/xdebug/commit/8d6392a51#diff-463e9f0296d2e3108dd01d49d3a11016f7b5f85048f4a56dc83c9341490b9e10L148), replacing the count with a simple binary indicator (1 for executed, 0 for not executed). During a discussion, Derick suspected that this change had been made back then to address the situation in which the number of times a line was executed was incremented for each statement on that line that was executed. Also in this discussion, Derick suggested the following improvements over the original implementation:

1) Implement the execution counting as a flag, allowing developers to opt into the more detailed reporting when needed rather than making it the default behavior.

2) Only count an execution if the line number differs from that of the previous execution. This would count how many times execution enters a particular line. This approach addresses the aforementioned issue, counting the line once per entry to it, rather than once per executed statement on it.

Currently, PHPUnit only reports the number of tests that executed a line. Once the change requested here is implemented, I will adapt PHPUnit's HTML code coverage report to show both the number of tests that executed a line of code ("distinct coverage") and the total number of times that line of code was executed during the execution of the test suite ("execution count"). Future work might include calculating and reporting additional software metrics derived from these two values.

0002369: Implement "Native Xdebug Path Mapping" project

Thu, 04 Dec 2025 14:50:36 +0000

More info at https://xdebug.org/funding/001-native-path-mapping

0002361: Uninitialised read when running mark_fse_as_having_line_breakpoints

Tue, 25 Nov 2025 14:22:01 +0000

```
diff --git src/debugger/debugger.c src/debugger/debugger.c
index d271b051..348e233a 100644
--- src/debugger/debugger.c
+++ src/debugger/debugger.c
@@ -557,6 +557,10 @@ static void mark_fse_as_having_line_breakpoints(function_stack_entry *fse)
continue;
}

+ if (!ZEND_USER_CODE(fse->op_array->type)) {
+ continue;
+ }
+
if (fse->function.type == XFUNC_EVAL) {
zend_string *resolved_filename;

```

0002297: Crash in exception handler

Tue, 25 Nov 2025 14:22:01 +0000

I'm working on a web application which uses Tracy to catch and report errors. However, when I run into an exception with Xdebug enabled then PHP often crashes (SIGSEGV) inside of Tracy. I was able to reduce the issue down from thousands of lines of code to 3 small files by gradually inlining and removing code. At this point it seems that I can't remove any more code.