MantisBT - Issues

0002437: systemd private /tmp path reported is incorrect

Tue, 01 Sep 2026 22:44:13 +0000

This is happening with Xdebug 3.5.3/PHP 8.3.33 on a SLES 15 SP7 system; I believe using the SUSE provided packages. The systemd private tmp path it reports in xdebug_info() and prepended to /tmp paths is incorrect and not actually the one used on the host. That is, with the mountinfo below, it reports that /tmp/systemd-private-57d3315f5ac2496098a5d7e5f2bbbea7-apache2.service-0oynxS is the path in use when the correct path to the /tmp seen by PHP outside of the process would be /tmp/systemd-private-57d3315f5ac2496098a5d7e5f2bbbea7-apache2.service-pwpfxr. The mountinfo for the process is below:

446 135 254:2 / / rw,relatime shared:326 master:1 - ext4 /dev/mapper/system-rootlv rw,discard
447 446 254:1 / /usr rw,relatime shared:352 master:2 - ext4 /dev/mapper/system-usrlv rw,discard,data=ordered
451 447 254:7 / /usr/local rw,relatime shared:353 master:82 - ext4 /dev/mapper/system-usrlocallv rw,discard,data=ordered
452 446 0:5 / /dev rw,nosuid shared:354 master:3 - devtmpfs devtmpfs rw,size=4096k,nr_inodes=4050823,mode=755,inode64
453 452 0:22 / /dev/shm rw,nosuid,nodev shared:355 master:4 - tmpfs tmpfs rw,size=43204380k,inode64
454 452 0:23 / /dev/pts rw,nosuid,noexec,relatime shared:356 master:5 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
455 452 0:31 / /dev/hugepages rw,nosuid,nodev,relatime shared:357 master:16 - hugetlbfs hugetlbfs rw,pagesize=2M
456 452 0:19 / /dev/mqueue rw,nosuid,nodev,noexec,relatime shared:358 master:17 - mqueue mqueue rw
464 446 0:21 / /sys rw,nosuid,nodev,noexec,relatime shared:359 master:6 - sysfs sysfs rw
465 464 0:6 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:360 master:7 - securityfs securityfs rw
466 464 0:25 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:361 master:8 - cgroup2 cgroup2 rw,nsdelegate,memory_recursiveprot
467 464 0:26 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:362 master:9 - pstore pstore rw
489 464 0:27 / /sys/firmware/efi/efivars rw,nosuid,nodev,noexec,relatime shared:363 master:10 - efivarfs efivarfs rw
581 464 0:28 / /sys/fs/bpf rw,nosuid,nodev,noexec,relatime shared:364 master:11 - bpf bpf rw,mode=700
582 464 0:12 / /sys/kernel/tracing rw,nosuid,nodev,noexec,relatime shared:365 master:18 - tracefs tracefs rw
583 464 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime shared:366 master:19 - debugfs debugfs rw
609 583 0:12 / /sys/kernel/debug/tracing rw,nosuid,nodev,noexec,relatime shared:367 master:836 - tracefs tracefs rw
610 464 0:32 / /sys/fs/fuse/connections rw,nosuid,nodev,noexec,relatime shared:368 master:20 - fusectl fusectl rw
611 464 0:33 / /sys/kernel/config rw,nosuid,nodev,noexec,relatime shared:369 master:21 - configfs configfs rw
612 446 0:20 / /proc rw,nosuid,nodev,noexec,relatime shared:370 master:12 - proc proc rw
613 612 0:30 / /proc/sys/fs/binfmt_misc rw,relatime shared:371 master:15 - autofs systemd-1 rw,fd=34,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17451
614 613 0:52 / /proc/sys/fs/binfmt_misc rw,nosuid,nodev,noexec,relatime shared:372 master:380 - binfmt_misc binfmt_misc rw
615 446 0:24 / /run rw,nosuid,nodev shared:373 master:13 - tmpfs tmpfs rw,size=6488004k,nr_inodes=819200,mode=755,inode64
621 615 0:47 / /run/vmblock-fuse rw,nosuid,nodev,relatime shared:375 master:215 - fuse.vmware-vmblock vmware-vmblock rw,user_id=0,group_id=0,default_permissions,allow_other
623 615 0:64 / /run/user/0 rw,nosuid,nodev,relatime shared:376 master:734 - tmpfs tmpfs rw,size=3244000k,nr_inodes=811000,mode=700,inode64
624 623 0:65 / /run/user/0/gvfs rw,nosuid,nodev,relatime shared:377 master:780 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0
625 623 0:66 / /run/user/0/doc rw,nosuid,nodev,relatime shared:378 master:797 - fuse.portal portal rw,user_id=0,group_id=0
626 615 0:51 / /run/user/1500 rw,nosuid,nodev,relatime shared:379 master:502 - tmpfs tmpfs rw,size=3244000k,nr_inodes=811000,mode=700,uid=1500,gid=1500,inode64
627 446 254:3 / /boot rw,relatime shared:383 master:70 - ext4 /dev/mapper/system-bootlv rw,discard,data=ordered
628 627 254:12 / /boot/grub2/i386-pc rw,relatime shared:384 master:91 - ext4 /dev/mapper/system-boot386 rw,discard,data=ordered
629 627 254:11 / /boot/grub2/x86_64-efi rw,relatime shared:385 master:94 - ext4 /dev/mapper/system-bootx64 rw,discard,data=ordered
630 627 8:1 / /boot/efi rw,relatime shared:386 master:100 - vfat /dev/sda1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro
631 446 254:10 / /home rw,relatime shared:494 master:73 - ext4 /dev/mapper/system-homelv rw,discard,data=ordered
632 446 254:9 / /opt rw,relatime shared:510 master:76 - ext4 /dev/mapper/system-optlv rw,discard,data=ordered
633 446 254:8 / /tmp rw,relatime shared:518 master:79 - ext4 /dev/mapper/system-tmplv rw,discard,data=ordered
634 446 254:5 / /srv rw,relatime shared:520 master:85 - ext4 /dev/mapper/system-srvlv rw,discard,data=ordered
635 634 254:4 / /srv/www rw,relatime shared:521 master:97 - ext4 /dev/mapper/system-srvwwwlv rw,discard,data=ordered
636 446 254:6 / /var rw,relatime shared:522 master:88 - ext4 /dev/mapper/system-varlv rw,discard,data=ordered
637 446 254:13 / /phprepo rw,relatime shared:541 master:457 - ext4 /dev/mapper/system-phprepo_lv rw,discard,data=ordered
616 615 0:24 /systemd/inaccessible/dir /run/credentials ro,nosuid,nodev,noexec shared:381 master:13 - tmpfs tmpfs rw,size=6488004k,nr_inodes=819200,mode=755,inode64
617 615 0:24 /systemd/propagate/apache2.service /run/systemd/incoming ro,nosuid,nodev master:13 - tmpfs tmpfs rw,size=6488004k,nr_inodes=819200,mode=755,inode64
618 633 254:8 /systemd-private-57d3315f5ac2496098a5d7e5f2bbbea7-apache2.service-pwpfxr/tmp /tmp rw,relatime shared:519 master:79 - ext4 /dev/mapper/system-tmplv rw,discard,data=ordered
619 636 254:6 /tmp/systemd-private-57d3315f5ac2496098a5d7e5f2bbbea7-apache2.service-0oynxS/tmp /var/tmp rw,relatime shared:523 master:88 - ext4 /dev/mapper/system-varlv rw,discard,data=ordered

I think the fact it doesn't begin with /tmp is what trips it up; it should probably be looking for the actual mount point being /tmp?

0002252: Running phpunit in coverage triggers segfault in xdebug_branch_info_mark_reached

Wed, 29 Jul 2026 13:23:08 +0000

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

0002434: Version 3.5.3, test failure on aarch64

Tue, 09 Jun 2026 09:13:25 +0000

Building version 3.5.3 and running the test suite

FAILED TEST SUMMARY
---------------------------------------------------------------------
Test for bug 0002424: Ctrl Socket: Aliveness after empty command [tests/debugger/bug02424-01.phpt]
Test for bug 0002424: Ctrl Socket: Command that doesn't exist [tests/debugger/bug02424-02.phpt]
Test for bug 0002424: Ctrl Socket: 'ps' command [tests/debugger/bug02424-03.phpt]
Test for bug 0002424: Ctrl Socket: Invalid command arguments [tests/debugger/bug02424-04.phpt]

All failing with
001+ PHP Warning: stream_socket_client(): Unable to connect to unix://\0xdebug-ctrl.32289 (Connection refused) in /tmp/11-bug02424-03 on line 3
002+ PHP Fatal error: Uncaught TypeError: stream_set_write_buffer(): Argument #1 ($stream) must be of type resource, false given in /tmp/11-bug02424-03:4

No problem on x86_64

May be a issue in PHP.

0002413: Suggestion: Develop mode in terminal

Wed, 03 Jun 2026 15:23:21 +0000

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

0002432: eval doesn't support functions like array_map and array_filter

Tue, 02 Jun 2026 20:30:23 +0000

This was very useful for extracting specific values from arrays of objects, and identifying patterns and counts meeting criteria within an array whilst debugging large data objects.

0002428: XDEBUG_MODE=develop and set_error_handler for deprecated null key in array

Fri, 29 May 2026 15:13:03 +0000

when an error handler is added in the code, the array does not support null keys (which are deprecated as of 8.5.x)

0002099: Filename path mapping, when using docker/container/vm

Thu, 28 May 2026 21:49:05 +0000

If xdebug provides information about files (e.g. stack traces), we can configure the way it works.

But on my host machine, the files have a different location, then on my guest machine. E.g.: /home/me/project/myapp VS /app

My wish is to have a configuration option, where i could replace a prefix filepath with another prefix.

Something like:
xdebug.file_map="/app /home/me/project/myapp"

0002396: xdebug eval can't define anonymous functions

Thu, 28 May 2026 14:57:23 +0000

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

0002406: Tests failing on armhf with PHP 8.5

Thu, 28 May 2026 14:56:41 +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.

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".