I haven’t had many problems with #PhpStorm’s #Xdebug integration in a long time. Most of the time, it Just Works, but today, it decided it doesn’t like me, and so now, my afternoon has been spent trying to get it to work again.
This is the error I see in the step debugging console. The only thing I know has changed is PhpStorm (it upgraded).
```
Cannot find file '/path/to/ramsey/uuid/Standard input code' locally.
```
I have this wired output when I run #PHPUNIT and #XDEBUG :
$ vendor/bin/phpunit --coverage-html coverage --coverage-text
PHPUnit 9.6.19 by Sebastian Bergmann and contributors.
Runtime: PHP 8.2.28 with Xdebug 3.4.4
Configuration: /.../phpunit.xml
double free or corruption (fasttop)
/bin/bash: line 158: 196 Aborted (core dumped) vendor/bin/phpunit --coverage-html coverage --coverage-text
Has someone seen this before? How to solve it? #PHP
Xdebug 3.4.4 Released!
This is a bug fix release that fixes a few crashes with regard to exceptions. This was a regression from Xdebug 3.4.3.
The full list of changes can be found on the updates page: https://xdebug.org/announcements/2026-06-12
In this monthly update I explain what happened with Xdebug development.
GitHub and Pro/Business supporters will get it earlier, around the first of each month.
In the last month, I spend around 20 hours on Xdebug, with 22 hours funded.
My apologies for missing several monthly reports.
Xdebug 3.4
Code Coverage with Fibers
Native Path Mapping
Xdebug Videos
Business Supporter Scheme and Funding
Xdebug Cloud
The slides for my "Better Debugging with @Xdebug" at @phptek are now online at https://derickrethans.nl/talks/xdebug-tek25
Xdebug 3.4.3 Released!
This is a bug fix release that fixes a few crashes.
It improves debugging with PHP 8.4's property hooks by recognising that they have code attached, and no longer throwing fatal errors or exceptions in some situations.
The full list of changes can be found on the updates page: https://xdebug.org/announcements/2025-05-14
I have created a new video!
In this video, I am showing off preliminary work on native path mapping.
This allows you to directly debug template files.
It will also work for situations where the PHP files that you edit, and which cat "compiled" into other PHP files that actually get executed.
https://www.youtube.com/watch?v=8tHKq_5-cXo (subtitles available)
For more information, and the specs, see the project page: https://xdebug.org/funding/001-native-path-mapping
@zapiz Xdebug is amazing, as others have suggested.
I also ensure full coverage with unit tests, using PHPUnit.
debug-tui now has a macos build - feel free to run a random binary from the internet and let me know if it works!
Thanks @derickr — Appreciate the well-designed API and detailed documentation.
I love #XDebug! For me it's an indispensable tool when I work on #php projects. But it's always a bit of a hassle to set it up. Maybe that's because I use Linux, maybe it's just me.
But some time ago, I started a new project, with @dunglas 's symfony-docker setup. And guess what: XDebug worked out of the box after I followed the steps in the documentation. So: a big shout-out for Kevin, for making this so easy! Thank you 
JetBrains Xdebug Helper Browser Extension
#PHP #PhpStorm #News #Xdebug
https://blog.jetbrains.com/phpstorm/2025/03/jetbrains-xdebug-helper/
Do you use VS Code and the PHP Debug plugin to use @Xdebug?
It'd mean the world to us to leave a nice/constructive review:
https://marketplace.visualstudio.com/items?itemName=xdebug.php-debug&ssr=false#review-details
I release a new version of Xdebug on Sunday, which fixes a few bugs. One of them is titled emoji character become diamond question marks. This bug turned out to be the same as var_dump does not output some Russian characters, which was originally reported a few days earlier but hadn't come with a decent enough reproducible case.
At first I dismissed this, as it's not unlikely that people get their character sets wrong, or mixed up.
But when I tested it, the following script really did not show the right result:
Instead of the expected:
Standard input code:3:string 'hello' (length=10)
It showed:
Standard input code:3:string 'hello ���' (length=10)
The four bytes that should have made up the had turned into three.
Xdebug uses a function, xdebug_xmlize, to escape XML and XHTML-special characters such as ", &, and < when it outputs strings of data.
Its algorithm first calculates how much memory the resulting string would use by looping over the source characters, and adding the lengths of the escaped characters together. It uses a 256-entry table for this.
The first row shows that byte 0's escaped length will be 4 (for �) and the LF character's escaped length will be 5 (for
).
The replacement strings are recorded in the table that follows. It only has place for 64 elements, as none of the bytes above byte-64 need to be escaped. You can see that because the xml_encode_count table only has entries containing 1 after the fourth 16-element row.
Then in a second iteration it loops over all the source characters again to construct the resulting output.
In this iteration, it checks if the destination length is 1, in which case it just copies the character over. If the destination length is not 1, then it adds the number of characters that correspond to the destination character's length.
The bug here was that the table for xml_encode_count, although it was defined as having 256 entries, only had 240 entries. I had missed to add the 16th line, so instead there were only 15 lines of 16 elements.
And in C, that means that these missing elements were all set to 0. This meant that if there was a character in the source string where the byte value was larger or equal to hexadecimal 0xF0 (decimal: 240), the algorithm thought the replacement length of these characters would be 0. This then resulted in these characters to just be ignored, and not copied over into the destination string.
For the character (hex: 0xF0 0x9F 0x91 0x8D) that meant that its first byte (0xF0) was not copied into the destination string. And that meant a broken UTF-8 character. Oops! 
In Xdebug 3.4.2 this is now fixed, as I have added the 16th line to the table, with 16 more elements containing 1.
What I did find curious that it took nearly five years for something to report this issue, and with that, two in the same week!
I have just released @Xdebug 3.4.2, which fixes:
two crashes
two memory leaks, through patches by @nielsdos an issue with showing the values of properties with hooks attached an issue where characters with higher order bits were not displayed when using Xdebug's overridden var_dump() function in HTML mode.
Read more about it at https://xdebug.org/announcements/2025-03-09
want fortnightly