#xdebug — Public Fediverse posts

For a long time I have heard complaints that Xdebug, with its debugger enabled, slows down applications, even if there is no IDE listening.

I have never been able to reproduce this, as on Linux (and macOS), TCP connections to a localhost ports fail immediately if that port is not open.

Xdebug waits for up to 200ms when making a debug connection. This is configurable with the xdebug.connect_timeout_ms setting.

But if there is nothing listening, there should not be any delay, as it ought to be an immediate error.

I wrote a comment in an issue from 2024:

It turns out, that it is not a firewall, but that Windows itself behaves bad here. Instead of failing immediately, it retry sending TCP SYN packets to try to establish a connection. This is pointless on the local loopback interface, as network packets cannot get lost.

Through a post by Daniel Stenberg on Mastodon, I found out the cause, and a solution.

He explains how it affects curl's Happy Eyeballs algorithm in a blog post from 2024. Although Xdebug does not use Happy Eyeballs, the underlying problem is the same.

Last week, Marcel Jamin wrote to the curl mailing list, with a solution. This solution disables the retry mechanism to establish a connection. And in turn that means, that there is no longer a delay on Windows either.

I have today merged a pull request for Xdebug which implements this solution. The patch is part of the upcoming Xdebug 3.6 release.

For a long time I have heard complaints that Xdebug, with its debugger enabled, slows down applications, even if there is no IDE listening.

I have never been able to reproduce this, as on Linux (and macOS), TCP connections to a localhost ports fail immediately if that port is not open.

Xdebug waits for up to 200ms when making a debug connection. This is configurable with the xdebug.connect_timeout_ms setting.

But if there is nothing listening, there should not be any delay, as it ought to be an immediate error.

I wrote a comment in an issue from 2024:

It turns out, that it is not a firewall, but that Windows itself behaves bad here. Instead of failing immediately, it retry sending TCP SYN packets to try to establish a connection. This is pointless on the local loopback interface, as network packets cannot get lost.

Through a post by Daniel Stenberg on Mastodon, I found out the cause, and a solution.

He explains how it affects curl's Happy Eyeballs algorithm in a blog post from 2024. Although Xdebug does not use Happy Eyeballs, the underlying problem is the same.

Last week, Marcel Jamin wrote to the curl mailing list, with a solution. This solution disables the retry mechanism to establish a connection. And in turn that means, that there is no longer a delay on Windows either.

I have today merged a pull request for Xdebug which implements this solution. The patch is part of the upcoming Xdebug 3.6 release.

Is there somebody who runs PHP on native windows (with Xdebug) and can run a simple script for me?

It must be in a file (`test.php`):
```
<?php
echo microtime(true), "\n";
xdebug_connect_to_client();
echo microtime(true), "\n";
```

And run like:

php -dxdebug.log_level=11 -dxdebug.log=c:\temp\xdebug-i.log -dxdebug.client_host=localhost -dxdebug.client_port=9111 -dxdebug.mode=debug c:\temp\test.php

With the port 9111 not open.

Would love to see the output and log file (in a DM).

#xdebug #php

Is there somebody who runs PHP on native windows (with Xdebug) and can run a simple script for me?

It must be in a file (`test.php`):
```
<?php
echo microtime(true), "\n";
xdebug_connect_to_client();
echo microtime(true), "\n";
```

And run like:

php -dxdebug.log_level=11 -dxdebug.log=c:\temp\xdebug-i.log -dxdebug.client_host=localhost -dxdebug.client_port=9111 -dxdebug.mode=debug c:\temp\test.php

With the port 9111 not open.

Would love to see the output and log file (in a DM).

#xdebug #php

Das absolut wichtigste Werkzeug, auf das ich beim Entwickeln von #PHPUnit Tests am wenigsten verzichten könnte?

#Xdebug

Die Arbeit mit Xdebug muss man sich angewöhnen. Wer bei meinem #Workshop am 11. September beim #TYPO3camp in München teilnimmt, lernt auch gleich mit Xdebug umzugehen.
Aber Vorsicht! Wer einmal damit angefängt, kann nicht mehr damit aufhören.

Tu nicht var-dumpen, komm lieber zum Camp: https://www.typo3camp-muenchen.de/

#TYPO3 #php

Das absolut wichtigste Werkzeug, auf das ich beim Entwickeln von #PHPUnit Tests am wenigsten verzichten könnte?

#Xdebug

Die Arbeit mit Xdebug muss man sich angewöhnen. Wer bei meinem #Workshop am 11. September beim #TYPO3camp in München teilnimmt, lernt auch gleich mit Xdebug umzugehen.
Aber Vorsicht! Wer einmal damit angefängt, kann nicht mehr damit aufhören.

Tu nicht var-dumpen, komm lieber zum Camp: https://www.typo3camp-muenchen.de/

#TYPO3 #php

In the last few weeks, I have been working through some bug reports for Xdebug, that resulted in the Xdebug 3.5.3 release.

These bug reports did not come solely from humans, but rather from a mix of humans using LLM assistant tools, focussing on security related problems, from two different sources and methodologies.

Although all of these issues where indeed bugs that I now have fixed, I don't think any of them can be classified even as having a low security impact.

But there was a whole host of other issues with these reports. The reports themselves can be unnaturally verbose — and also fairly alarmist using terms like "victim" and "attacker". The tests that were present in the reports were often minimal, and sometimes incomplete, and so were some of their suggested fixes.

The humans forwarding the reports took care not to flood the issue tracker with reports out of the blue, and reached out to me first. They've also been helpful discussing the reported issues.

The first four cases were reported by Ilia Alshanetsky, a long time, and recently returned, contributor to PHP.

The first report, #2421, deals with sending wrong option characters with commands through the DBGp protocol, that an IDE and Xdebug use to communicate.

Xdebug would allocate an array for 27 of these, representing the 26 lower case letters of the Latin alphabet, and the - character. What Xdebug did not do is to make sure the option letters were indeed in the range [a-z-], and would happily accept -@ or -\x00. This makes it possible to overwrite locations in memory.

The suggested patch was fine, but the test that went with it was very hard to read. It didn't use already exiting framework for testing the step debugger either — I had to add my own.

I also believe that this issue could as easily have been found by a fuzzer, which I added now as well. The fuzzer found the same problem in about five seconds, and luckily, nothing else either.

The second issue, #2422 complained that there was no limit in the debugger's code that reads commands from the network.

The patch was mostly fine, but the test was wholly cumbersome again — it didn't use the already existing testing framework either. It also picked a funnily large (arbitrary) limit of 64MB for DBGp commands, where 64KB would easily suffice — in most cases, 256 bytes would have been fine.

The third issue, #2423, argues that Xdebug shouldn't follow symlinks when creating profiling or trace files.

The patch was OK and trivial, but the test was again very hard to read making it hard to figure out what it as trying to do. It also did not make use of some existing helpers to skip tests. It came up with:

--SKIPIF--
<?php
if (PHP_OS_FAMILY === 'Windows') die('skip: Linux-only symlink semantics');
?>

Instead of what is used everywhere else:

--SKIPIF--
<?php
require __DIR__ . '/../utils.inc';
check_reqs('!win');
?>

The fourth and last issue through Ilia, #2424, deals with Xdebug's Control Socket functionality, where its parser would not handle empty or large command packets correctly. The LLM proposed patch fixed the symptoms, but not the actual cause of this issue.

The second set of reports were shared with me in a private gist by Volker, as part of the PHP Foundation's Ecosystem Security Team effort.

The first one was a duplicate of bug #2421. The test focussed on the Control Socket functionality instead of the Step Debugger, but the underlying issue and fix were the same.

The second issue I added as bug #2433. When you enable xdebug.collect_assignments with tracing, Xdebug needs to re-create the variable name from several opcodes in order to show this name in a readable way.

But the issue is not a real time problem, insofar this can only happen if you run PHP code on the command line through the -r option, xdebug.start_with_request is yes. For some reason, when PHP runs code through -r, the CLI binary does not generate EXT_STMT opcodes (Xdebug uses these for breaking during step-debugging), which would otherwise prevent the out-of-bound memory read from happening.

The LLM tool also hadn't realised that the third argument to the function responsible for reassembling the variable name was always NULL, and hence superfluous.

I addressed these both through the same commit, and added a test, which would not exhibit the problem in most situations either. It is still good to have the expected outcome documented.

Another report resulted in two issues in Xdebug's tracker. #2427 addresses an incorrect memory read if the xdebug.file_link_format setting ends with a lone %, and #2429, a similar report, but then for xdebug.trace_output_name.

Although the report mentioned three locations, the accompanying test only covered one of three situations where this was a problem: for trace file names, but not formatting link files through xdebug.file_link_format, nor profiling files.

The patch it suggested was also wrong, as it would remove the trailing % instead of keeping it. One of three locations where the trailing % was not handled, was internal only, and hence couldn't be triggered by making configuration errors.

The test that came with this report did not help me trying to show the problem. It relied on AddressSanitizer to show any problems, but I could not get that to happen. All the tests through this tool also provided tests that tested that the was present, and not what the correct result ought to be.

Luckily, using the Xdebug test suite with the valgrind tool showed the problem.

A further report, #2430 showed a problem if either an IDE through the step debugging protocol, or a developer directly, would request the contents of a "variable" named :::. The step debugger uses :: to indicate "all the static variables for this class", and following that up with a : isn't valid.

The fix was good, but I couldn't directly use the test case, as it tested for the broken behaviour. The test was fairly trivial to write as the reproduce case in the reported test case was correct.

And the last issue from the second list, #2431, again reinvented its own way for doing DBGp tests, and also tested that the behaviour was wrong, instead of a test to show that it now works.

Even with the code fixed, the new correct test would also surface another issue, as it would have resulted in Xdebug to open a directory as it was a file, and then fail.

: Although the LLM tools did find bugs, they were not particularly groundbreaking. Some of the bugs would also have been found by fuzzing, and used a lot less resources in that process.

Most of the crashes and potential security issues would only be a problem if an attacker didn't already have access to the machine that the code runs on itself, or have an IDE talking to Xdebug already.

If you have access to the machine, you can do worse without these bugs present. If you have client access to Xdebug through DBGp, you would have all the functionality that PHP provides, including reading all files on the file system and running code.

The generated test cases were generally hard to read, or incomplete. The patches that the models came up with were not always comprehensive, or correct. I also spent too much time getting AddressSanitizer to do anything, unsuccessfully.

I think I would have been as quick writing these patches and actual test cases myself, when provided with the issues' causes and the reasoning that was provided.

I don't think I'll be spending time trying to get these tools to work myself, but in the right hands with people that know what they're doing, they can find issues that needs to be addressed. But the value comes from the humans interpreting their results.

In the last few weeks, I have been working through some bug reports for Xdebug, that resulted in the Xdebug 3.5.3 release.

These bug reports did not come solely from humans, but rather from a mix of humans using LLM assistant tools, focussing on security related problems, from two different sources and methodologies.

Although all of these issues where indeed bugs that I now have fixed, I don't think any of them can be classified even as having a low security impact.

But there was a whole host of other issues with these reports. The reports themselves can be unnaturally verbose — and also fairly alarmist using terms like "victim" and "attacker". The tests that were present in the reports were often minimal, and sometimes incomplete, and so were some of their suggested fixes.

The humans forwarding the reports took care not to flood the issue tracker with reports out of the blue, and reached out to me first. They've also been helpful discussing the reported issues.

The first four cases were reported by Ilia Alshanetsky, a long time, and recently returned, contributor to PHP.

The first report, #2421, deals with sending wrong option characters with commands through the DBGp protocol, that an IDE and Xdebug use to communicate.

Xdebug would allocate an array for 27 of these, representing the 26 lower case letters of the Latin alphabet, and the - character. What Xdebug did not do is to make sure the option letters were indeed in the range [a-z-], and would happily accept -@ or -\x00. This makes it possible to overwrite locations in memory.

The suggested patch was fine, but the test that went with it was very hard to read. It didn't use already exiting framework for testing the step debugger either — I had to add my own.

I also believe that this issue could as easily have been found by a fuzzer, which I added now as well. The fuzzer found the same problem in about five seconds, and luckily, nothing else either.

The second issue, #2422 complained that there was no limit in the debugger's code that reads commands from the network.

The patch was mostly fine, but the test was wholly cumbersome again — it didn't use the already existing testing framework either. It also picked a funnily large (arbitrary) limit of 64MB for DBGp commands, where 64KB would easily suffice — in most cases, 256 bytes would have been fine.

The third issue, #2423, argues that Xdebug shouldn't follow symlinks when creating profiling or trace files.

The patch was OK and trivial, but the test was again very hard to read making it hard to figure out what it as trying to do. It also did not make use of some existing helpers to skip tests. It came up with:

--SKIPIF--
<?php
if (PHP_OS_FAMILY === 'Windows') die('skip: Linux-only symlink semantics');
?>

Instead of what is used everywhere else:

--SKIPIF--
<?php
require __DIR__ . '/../utils.inc';
check_reqs('!win');
?>

The fourth and last issue through Ilia, #2424, deals with Xdebug's Control Socket functionality, where its parser would not handle empty or large command packets correctly. The LLM proposed patch fixed the symptoms, but not the actual cause of this issue.

The second set of reports were shared with me in a private gist by Volker, as part of the PHP Foundation's Ecosystem Security Team effort.

The first one was a duplicate of bug #2421. The test focussed on the Control Socket functionality instead of the Step Debugger, but the underlying issue and fix were the same.

The second issue I added as bug #2433. When you enable xdebug.collect_assignments with tracing, Xdebug needs to re-create the variable name from several opcodes in order to show this name in a readable way.

But the issue is not a real time problem, insofar this can only happen if you run PHP code on the command line through the -r option, xdebug.start_with_request is yes. For some reason, when PHP runs code through -r, the CLI binary does not generate EXT_STMT opcodes (Xdebug uses these for breaking during step-debugging), which would otherwise prevent the out-of-bound memory read from happening.

The LLM tool also hadn't realised that the third argument to the function responsible for reassembling the variable name was always NULL, and hence superfluous.

I addressed these both through the same commit, and added a test, which would not exhibit the problem in most situations either. It is still good to have the expected outcome documented.

Another report resulted in two issues in Xdebug's tracker. #2427 addresses an incorrect memory read if the xdebug.file_link_format setting ends with a lone %, and #2429, a similar report, but then for xdebug.trace_output_name.

Although the report mentioned three locations, the accompanying test only covered one of three situations where this was a problem: for trace file names, but not formatting link files through xdebug.file_link_format, nor profiling files.

The patch it suggested was also wrong, as it would remove the trailing % instead of keeping it. One of three locations where the trailing % was not handled, was internal only, and hence couldn't be triggered by making configuration errors.

The test that came with this report did not help me trying to show the problem. It relied on AddressSanitizer to show any problems, but I could not get that to happen. All the tests through this tool also provided tests that tested that the was present, and not what the correct result ought to be.

Luckily, using the Xdebug test suite with the valgrind tool showed the problem.

A further report, #2430 showed a problem if either an IDE through the step debugging protocol, or a developer directly, would request the contents of a "variable" named :::. The step debugger uses :: to indicate "all the static variables for this class", and following that up with a : isn't valid.

The fix was good, but I couldn't directly use the test case, as it tested for the broken behaviour. The test was fairly trivial to write as the reproduce case in the reported test case was correct.

And the last issue from the second list, #2431, again reinvented its own way for doing DBGp tests, and also tested that the behaviour was wrong, instead of a test to show that it now works.

Even with the code fixed, the new correct test would also surface another issue, as it would have resulted in Xdebug to open a directory as it was a file, and then fail.

: Although the LLM tools did find bugs, they were not particularly groundbreaking. Some of the bugs would also have been found by fuzzing, and used a lot less resources in that process.

Most of the crashes and potential security issues would only be a problem if an attacker didn't already have access to the machine that the code runs on itself, or have an IDE talking to Xdebug already.

If you have access to the machine, you can do worse without these bugs present. If you have client access to Xdebug through DBGp, you would have all the functionality that PHP provides, including reading all files on the file system and running code.

The generated test cases were generally hard to read, or incomplete. The patches that the models came up with were not always comprehensive, or correct. I also spent too much time getting AddressSanitizer to do anything, unsuccessfully.

I think I would have been as quick writing these patches and actual test cases myself, when provided with the issues' causes and the reasoning that was provided.

I don't think I'll be spending time trying to get these tools to work myself, but in the right hands with people that know what they're doing, they can find issues that needs to be addressed. But the value comes from the humans interpreting their results.

Интеграция xdebug в свой проект idea

Одной из первых задач, когда я начинал разработку idea, была интеграция xdebug в свой инструмент разработки и реализация основных возможностей работы дебагера. Первым делом надо было изучить документация по протоколу xdebug. В нем используется общий протокол дебагера DBGP. В целом ничего сложного, есть сокет через который мы отправляем команды в сам xdebug он нам отвечает в формате xml, парсим xml и получаем результат. Все просто подумал Я, но как всегда не без приключений. Первая проблема возникла от недопонимания в какой момент создается сокет, тот самый порт 9000. Читаем документацию пункт 5.3 и 5.4 первый говорит про стандартный порт второй пункт говорит о инициализации подключения и что xdebug отвечает при готовности объектом <init>

https://habr.com/ru/articles/1043900/

#javafx #xdebug #java #socket

Coding at the Speed of Thought: The New Era of Symfony Docker

https://dunglas.dev/2026/03/coding-at-the-speed-of-thought-the-new-era-of-symfony-docker/

Coding at the Speed of Thought: The New Era of Symfony Docker

https://dunglas.dev/2026/03/coding-at-the-speed-of-thought-the-new-era-of-symfony-docker/

[Fatal #Error] :2:8231008: JAXP00010003: The length of entity "[#xml]" is "100,001" that exceeds the "100,000" limit set by "jdk.xml.maxGeneralEntitySizeLimit".

#Java #Memory #NetBeans #PHP #XDebug

#MissionAccomplished

[Fatal #Error] :2:8231008: JAXP00010003: The length of entity "[#xml]" is "100,001" that exceeds the "100,000" limit set by "jdk.xml.maxGeneralEntitySizeLimit".

#Java #Memory #NetBeans #PHP #XDebug

#MissionAccomplished

Was it ever a goal of software development to make something as fast & narrowly functional as possible while turning the innards of it to code soup?

No?

Then why is this ridiculous #AI #xdebug fork in my LinkedIn feed? 😮‍💨

Was it ever a goal of software development to make something as fast & narrowly functional as possible while turning the innards of it to code soup?

No?

Then why is this ridiculous #AI #xdebug fork in my LinkedIn feed? 😮‍💨

Came across this repository and was wondering if this is legit or just some random ai work: https://github.com/pronskiy/php-debugger

#Xdebug #PHP #phpcommunity

I also think this is for @derickr

Came across this repository and was wondering if this is legit or just some random ai work: https://github.com/pronskiy/php-debugger

#Xdebug #PHP #phpcommunity

I also think this is for @derickr

When it comes to performance debugging, there are a wide variety of tools available. The last years, I searched for one that is actually easily usable and provides easy access in identifying bottlenecks.

There are some that are specific to WordPress, e.g. as plugins, some allow general performance debugging via PHP and some require a PHP extension to be loaded. I’ll cover all of these types in the following article.

[…]

Wenn es um Performance-Debugging geht, gibt es eine Menge verfügbarer Werkzeuge. In den letzten Jahren habe ich nach einem gesucht, das wirklich leicht verwendbar ist und Engpässe selbst gut erkennt.

Es gibt einige, die spezifisch für WordPress sind, beispielsweise als Plugins, und einige für generelles Performance-Debugging in PHP. Andere wiederum benötigen eine bestimmte PHP-Erweiterung. Im folgenden Artikel decke ich alle möglichen Typen ab.

[…]

I'm thrilled to announce that I'll be speaking at the 23rd edition of #phpday, the international PHP conference in Italy, organised by @grusp.

I’ll be presenting a talk titled: "Better Debugging With Xdebug".

It's in Verona, Italy, on May 14-15th 2026.

You can use my speaker’s discount code "speaker_10OFF" for 10% off at https://www.phpday.it/tickets/?utm_medium=organic&utm_source=linkedin&utm_campaign=post-speaker

#PHP #Xdebug #Debugging

I'm thrilled to announce that I'll be speaking at the 23rd edition of #phpday, the international PHP conference in Italy, organised by @grusp.

I’ll be presenting a talk titled: "Better Debugging With Xdebug".

It's in Verona, Italy, on May 14-15th 2026.

You can use my speaker’s discount code "speaker_10OFF" for 10% off at https://www.phpday.it/tickets/?utm_medium=organic&utm_source=linkedin&utm_campaign=post-speaker

#PHP #Xdebug #Debugging

Last year I visited 2 big European CMS #flagship events.

One where a talk about sustainability was scheduled in a side event in a basement.
The other where a talk about this was scheduled in the regular main event scheme featuring a joint presentation from Drupal and Typo3 folks.
Also, in this the second event, had presentationf by #PHPUnit (Sebastian Bergman) and #xDebug (Derick Rethans).

Want to guess the #openSource #CMS - names from both events?

Last year I visited 2 big European CMS #flagship events.

One where a talk about sustainability was scheduled in a side event in a basement.
The other where a talk about this was scheduled in the regular main event scheme featuring a joint presentation from Drupal and Typo3 folks.
Also, in this the second event, had presentationf by #PHPUnit (Sebastian Bergman) and #xDebug (Derick Rethans).

Want to guess the #openSource #CMS - names from both events?

Me: "Why won't this app break on this line!?"

Also me: Helps to have #xdebug enabled if you're trying to debug something :blobcatfacepalm:

#php

Me: "Why won't this app break on this line!?"

Also me: Helps to have #xdebug enabled if you're trying to debug something :blobcatfacepalm:

#php

A third-party #Composer plugin is breaking my Composer scripts and I can't trouble-shoot it because #PhpStorm is unable to step debug into Composer phar archive, even though 13yo blog articles suggest it should, and my command's code is not even called when the plugin is enabled. I can't find any setting related to this, and I don't want to fiddle with my setup to run Composer from source.
#php #xdebug

A third-party #Composer plugin is breaking my Composer scripts and I can't trouble-shoot it because #PhpStorm is unable to step debug into Composer phar archive, even though 13yo blog articles suggest it should, and my command's code is not even called when the plugin is enabled. I can't find any setting related to this, and I don't want to fiddle with my setup to run Composer from source.
#php #xdebug

In this update I explain what happened with Xdebug development in the last month.

In the last month, I spent only around 9 hours on Xdebug, with 24 hours funded. The rest of the time, I spend on building out Xdebug Cloud version 2.

Xdebug 3.5

Most of this month I spent on a few bug and performance reports from the Xdebug 3.5 release — most notable a performance degradation on Windows due to the new experimental control sockets.

I also spent time on my large better code coverage patch, which still isn't quite as performant as the current feature; although it does give more precise results.

Native Path Mapping

Fabian Potencier, from Symfony fame, has created an exploratory patch for Twig to make use of Xdebug's new Native Path Mapping functionality.

From the initial patch, it became clear that a few things need to be improved on the Xdebug side for this to be a complete feature. For that reason, I have created a few issues to work on:

• Invent better way of configuring lots of line-to-line mappings

• Create xdebug_add_source_map_directory() function to dynamically add directories where Xdebug will load path mapping files from

• Add EOF marker/stanza to native path file mapper

My PhpStorm issue to allow for the setting of breakpoints in template file has now been merged, and is scheduled for 2026.1 EAP 2. At the time of writing this isn't quite out yet, so I will keep you posted.

Xdebug Videos

I have created one new videos in the last month:

• Xdebug 3: Interrupting Long Running Scripts with VS Code for Debugging

All Xdebug videos are now available on the phpc.tv PeerTube instance. This will be the primary location for new videos, although I also still post them to my YouTube channel.

If you have any suggestions, feel free to reach out to me on Mastodon or via email.

Xdebug Cloud

I am currently reworking Xdebug Cloud, the Proxy As A Service platform to allow for debugging in complex networking scenarios.

The new version will allow for automatic subscriptions.

Packages will start at £16/month for one-developer companies.

If you want to be kept up to date with Xdebug Cloud, please sign up to the mailing list, which I will use to send out an update not more than once a month.

In this update I explain what happened with Xdebug development in the last month.

In the last month, I spent only around 9 hours on Xdebug, with 24 hours funded. The rest of the time, I spend on building out Xdebug Cloud version 2.

Xdebug 3.5

Most of this month I spent on a few bug and performance reports from the Xdebug 3.5 release — most notable a performance degradation on Windows due to the new experimental control sockets.

I also spent time on my large better code coverage patch, which still isn't quite as performant as the current feature; although it does give more precise results.

Native Path Mapping

Fabian Potencier, from Symfony fame, has created an exploratory patch for Twig to make use of Xdebug's new Native Path Mapping functionality.

From the initial patch, it became clear that a few things need to be improved on the Xdebug side for this to be a complete feature. For that reason, I have created a few issues to work on:

• Invent better way of configuring lots of line-to-line mappings

• Create xdebug_add_source_map_directory() function to dynamically add directories where Xdebug will load path mapping files from

• Add EOF marker/stanza to native path file mapper

My PhpStorm issue to allow for the setting of breakpoints in template file has now been merged, and is scheduled for 2026.1 EAP 2. At the time of writing this isn't quite out yet, so I will keep you posted.

Xdebug Videos

I have created one new videos in the last month:

• Xdebug 3: Interrupting Long Running Scripts with VS Code for Debugging

All Xdebug videos are now available on the phpc.tv PeerTube instance. This will be the primary location for new videos, although I also still post them to my YouTube channel.

If you have any suggestions, feel free to reach out to me on Mastodon or via email.

Xdebug Cloud

I am currently reworking Xdebug Cloud, the Proxy As A Service platform to allow for debugging in complex networking scenarios.

The new version will allow for automatic subscriptions.

Packages will start at £16/month for one-developer companies.

If you want to be kept up to date with Xdebug Cloud, please sign up to the mailing list, which I will use to send out an update not more than once a month.

Question about #php #xdebug
I have in parallel openTelemetry for tracing running on local. I would like to add a span, if xdebug stops for a breakpoint.
Is there any type of hook or magic possible/available?

Question about #php #xdebug
I have in parallel openTelemetry for tracing running on local. I would like to add a span, if xdebug stops for a breakpoint.
Is there any type of hook or magic possible/available?

Exit VSCode, enter #VSCodium, binary versions of the VSCode editor with all telemetry and tracking disabled by default.

It's a drop-in replacement for VSCode and has been working perfectly for me, including its #xdebug integration.

➡️ https://vscodium.com

Exit VSCode, enter #VSCodium, binary versions of the VSCode editor with all telemetry and tracking disabled by default.

It's a drop-in replacement for VSCode and has been working perfectly for me, including its #xdebug integration.

➡️ https://vscodium.com

debug tui can now accept a script as an argument and monitors the stdout/stderr. also blinking lights. #xdebug #php

https://github.com/dantleech/debug-tui

debug tui can now accept a script as an argument and monitors the stdout/stderr. also blinking lights. #xdebug #php

https://github.com/dantleech/debug-tui

RE: https://phpc.social/@phpc_tv/115913656275791585

@phpc_tv wow so many vids in there! Awesome!

#php #phpc #composerphp #xdebug # #peertube

RE: https://phpc.social/@phpc_tv/115913656275791585

@phpc_tv wow so many vids in there! Awesome!

#php #phpc #composerphp #xdebug # #peertube

Schritt-für-Schritt-Anleitung fürs PHP Debugging mit Xdebug: 

Auf unserem Managed Server stellen wir die PHP-Erweiterung Xdebug zur Verfügung.

Xdebug ermöglicht es dir, deinen Code mit dem Setzen von Breakpoints oder der Überwachung von Variablen zu debuggen.

In unserem neusten Blogpost erklärt @Markus, wie du Xdebug einrichten und verwenden kannst.

Hier gehts zum Artikel: https://opsone.ch/de/blog/php-debugging-mit-xdebug

#xDebug #ManagedServer #OpenSource #SwissHosting #DevOps

Schritt-für-Schritt-Anleitung fürs PHP Debugging mit Xdebug: 

Auf unserem Managed Server stellen wir die PHP-Erweiterung Xdebug zur Verfügung.

Xdebug ermöglicht es dir, deinen Code mit dem Setzen von Breakpoints oder der Überwachung von Variablen zu debuggen.

In unserem neusten Blogpost erklärt @Markus, wie du Xdebug einrichten und verwenden kannst.

Hier gehts zum Artikel: https://opsone.ch/de/blog/php-debugging-mit-xdebug

#xDebug #ManagedServer #OpenSource #SwissHosting #DevOps

The fact that the word #Docker isn't used anywhere on this page is fucking insane!
wtf are people using out there?

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

Anyway, in case you didn't notice: #php #Xdebug (finally) supports path mapping, something every tool should provide!

The fact that the word #Docker isn't used anywhere on this page is fucking insane!
wtf are people using out there?

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

Anyway, in case you didn't notice: #php #Xdebug (finally) supports path mapping, something every tool should provide!

In this update I explain what happened with Xdebug development in the last month.

In the last month, I spent around 28 hours on Xdebug, with 24 hours funded.

Xdebug 3.5

Most of this month I spent on making Xdebug 3.5 ready, to coincide with the release of PHP 8.5.

First there were a few bug reports from the alpha releases, and I found some issues with the new Native Path Mapping myself. I also fixed a crash bug, and released the last pre-release version: 3.5.0alpha3.

After that release, I worked with the author of the PHP Debug Adapter for Visual Studio Code to bring Xdebug's control sockets to Windows. This held up the release of Xdebug 3.5 a little, as we wanted to get this right.

With this, I also created documentation for the Xdebug Control tool, which can be used to talk to Xdebug to initiate debugging sessions, and to force pausing running code without setting a breakpoint beforehand. This is only available on Linux and Windows.

Documentation Upgrades

While working on the documentation for the Xdebug Control tool, I went down the rabbit hole, and revamped the layout of the documentation's front page too. Instead of a single list with bullet points, there are now sections, and some images depicting the different features.

I also added a section on Flame Graphs. This feature that I added in Xdebug 3.3 was not yet documented.

PIE and PECL

I also documented how to install Xdebug with PIE, the new installer for PHP extensions based around the packagist ecosystem.

PIE is replacing the legacy PECL tool and website. Installing Xdebug with PECL is no longer the preferred installation method. Using PIE is strongly recommended.

In the future, there will no longer be new versions of Xdebug uploaded to the PECL website. In the mean time, releases through PECL will be delayed.

Xdebug Videos

I have created no new videos in the last months.

All Xdebug videos can be watched on my channel.

If you have any suggestions, feel free to reach out to me on Mastodon or via email.

Business Supporter Scheme and Funding

On GitHub sponsors, I am currently 42% 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, no new business supporters signed up.

Besides business support, I also maintain a Patreon page, a profile on GitHub sponsors, as well as an OpenCollective organisation.

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 mailing list, which I will use to send out an update not more than once a month.

I'm surprised there isn't more noise about #PhpStorm debugger showing PHP lazy objects used by #Doctrine as "Collecting data...". I wonder if there's something in our #Symfony or #PHP setup that triggers this bug and it's otherwise uncommon. It seems everything's alright at #Xdebug side, but there's hardly any movement in JetBrains issue tracker.

I'm surprised there isn't more noise about #PhpStorm debugger showing PHP lazy objects used by #Doctrine as "Collecting data...". I wonder if there's something in our #Symfony or #PHP setup that triggers this bug and it's otherwise uncommon. It seems everything's alright at #Xdebug side, but there's hardly any movement in JetBrains issue tracker.

RE: https://phpc.social/@Xdebug/115662135830755552

I have just released Xdebug 3.5.0!

In the next few weeks I will create some content (text, and perhaps video) highlighting some new features in more detail.

Please share it with the world!

#php #php85 #xdebug #debugging

RE: https://phpc.social/@Xdebug/115662135830755552

I have just released Xdebug 3.5.0!

In the next few weeks I will create some content (text, and perhaps video) highlighting some new features in more detail.

Please share it with the world!

#php #php85 #xdebug #debugging

It must be the first of the month, because the GitHub sponsor cancellations are coming in again.

Instead of spending money on things that you don't need on this #cybermonday, support the maintainers of the open source projects who help you create the software that powers your site.

For @Xdebug that could be through:
- GitHub sponsors: https://github.com/sponsors/derickr
- Directly with an invoice: https://xdebug.org/support
- Signing up and using Xdebug Cloud: https://xdebug.cloud/

#php #xdebug #sponsor

It must be the first of the month, because the GitHub sponsor cancellations are coming in again.

Instead of spending money on things that you don't need on this #cybermonday, support the maintainers of the open source projects who help you create the software that powers your site.

For @Xdebug that could be through:
- GitHub sponsors: https://github.com/sponsors/derickr
- Directly with an invoice: https://xdebug.org/support
- Signing up and using Xdebug Cloud: https://xdebug.cloud/

#php #xdebug #sponsor

My current dev setup uses a dockerised PHP install, PHPStorm and Xdebug. This works fine as expected, but whenever I launch an async process that's picked up by a queue worker.. I lose the ability to use xdebug.

Is there something I'm missing in my setup that would indeed offer this functionality? Anyone else happen to have this setup working? Working with logs for debugging is becoming tedious, especially for batched and chained jobs.

#xdebug #phpstorm #docker #debugging

@markusstaab @beberlei I've added comments, but let me repeat them:

- Would this "description" be in addition to the normal properties, or replace the existing ones?
- What should the name of this fake "description" property be? (I usually use $__UPPERCASE_NAME, like for $__RETURN_VALUE and $__INTERMEDIATE_VALUE).
- Does it matter whether it returns a string or mixed? The IDE should be able to render it regardless.

#php #xdebug

@markusstaab @beberlei I've added comments, but let me repeat them:

- Would this "description" be in addition to the normal properties, or replace the existing ones?
- What should the name of this fake "description" property be? (I usually use $__UPPERCASE_NAME, like for $__RETURN_VALUE and $__INTERMEDIATE_VALUE).
- Does it matter whether it returns a string or mixed? The IDE should be able to render it regardless.

#php #xdebug

Xdebug Update: October 2025. #Xdebug #PHP

https://derickrethans.nl/xdebug-update-october-2025.html?utm_source=flipboard&utm_medium=activitypub

Posted into SYMFONY FOR THE DEVIL @symfony-for-the-devil-mobileatom

#docker #Bitnami ist für mich endgültig gestorben.

Erst verlieren neuere #PHP Versionen #XDebug, und jetzt für #Postgres, #Apache , ....

bitnami/apache:latest not found: manifest unknown: manifest unknown

F*uck you, so geht's nicht. Wieder sinnlose arbeit für mich.

@sylbru Also since #PHP has so many deployment methods ( CLI, FPM, MOD_PHP, etc) and #XDebug needs different configurations for them and each project has different deployment requirements, it makes it difficult remember which configuration goes to which setup.

@sylbru Yea. I have similar experiences with #XDebug. It is more about me using it more irregularly than the fault of Xdebug.