more refactoring this morning - history mode now captures the current context so you can browse past state - and I combined the "history" view into the "session" view and the next step will be using <tab> to select focus and scroll the source/property-list up and down #php#xdebug#rust
made some practical improvements today including a COMMAND mode to enter raw DBGP commands (e.g. set a breakpoint)- so that I can start using it for work tomorrow.
My next feature will either be the ability to go "back" in the history or to show the local vars / properties. #php#xdebug#rust
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
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!
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.
In the last month, I spend around 18 hours on Xdebug, with 25 hours funded.
Xdebug 3.4
At the start of the month I released Xdebug 3.4.1, which fixes a few crash bugs when deciding whether to activate a specific feature.
During the rest of the month, I fixed an issue where PHP 8.4's new property hooks would not show their content in the debugger.
Foreach Woes
Besides the Xdebug 3.4 general bug fixes, I have also been looking at addressing a long-standing issue where using foreach produces some unexpected results when doing path and branch coverage. I wrote an article called Figuring Out Foreach to explain the problem.
The fix however is trickier, and I am inclined to roll that up into a big patch that refactors Code Coverage into an analysis pass, and a collection pass. The patch sits in a branch and addresses some other long outstanding inaccuracies.
I recently have rebranched this patch on Xdebug's master again, so it is fully functional (minus the foreach changes), but unfortunately it is a little slower than what currently is available in Xdebug. I might decide to release it with this slight performance degradation in Xdebug 3.5 or 3.6 regardless.
Xdebug Videos
I have created one new video in the last two months:
If you want to contribute to specific projects, you can find those on the Projects page.
Xdebug Cloud
Xdebug Cloud is the Proxy As A Service platform to allow for debugging in more scenarios, where it is hard, or impossible, to have Xdebug make a connection to the IDE. It is continuing to operate as Beta release.
Packages start at £49/month, and I have recently introduced a package for larger companies. This has a larger initial set of tokens, and discounted extra tokens.
If you want to be kept up to date with Xdebug Cloud, please sign up to the mailinglist, which I will use to send out an update not more than once a month.
11 more days to fulfill my last year resolution - to use #Emacs as IDE for #Drupal development. What's been holding me back is the debugger (#xdebug). I know about three packages #geben, #dap and #dape, but I don't know which to choose. Would you recommend me one? I'm a bit hesitant to use nodejs based solution, but only a bit. Anyone uses any of these tools?
@tassoman I used to be on team var_dump() for many years, until I saw the light and switch to #Xdebug. I’m not sure how I ever wrote code without a step debugger before!
Now with Xdebug 3.4 out, I've made a video explaining its experimental "Control Socket" feature, and a slightly older feature function called xdebug_connect_to_client().
On GitHub sponsors, I am currently 43% towards my $2,500 per month goal, which is set to allow continued of Xdebug.
If you are leading a team or company, then it is also possible to support Xdebug through a subscription.
In the last month, I spend around 10 hours on Xdebug, with 22 hours funded.
Xdebug 3.4
PHP 8.4 was released at the end of November, and with that it was also necessary to release Xdebug 3.4 with support for it. Before I did that, I had another good look at many issues to try to find out what the problem was.
I fixed a few issues, and another set of issues disappeared due to fixes in PHP itself.
If you find any issues with Xdebug 3.4, then please send me a bug report through the issue tracker.
Xdebug Videos
I have created no new Xdebug videos in the last month, but there is a new video in my "Writing Extensions" series.
If you want to contribute to specific projects, you can find those on the Projects page.
Xdebug Cloud
Xdebug Cloud is the Proxy As A Service platform to allow for debugging in more scenarios, where it is hard, or impossible, to have Xdebug make a connection to the IDE. It is continuing to operate as Beta release.
Packages start at £49/month, and I have recently introduced a package for larger companies. This has a larger initial set of tokens, and discounted extra tokens.
If you want to be kept up to date with Xdebug Cloud, please sign up to the mailinglist, which I will use to send out an update not more than once a month.
