Change 502495 had a related patch set uploaded (by Jgleeson; owner: Jgleeson):
[mediawiki/vagrant@master] WIP: Add support for xdebug in php7.2

https://gerrit.wikimedia.org/r/502495

Change 502495 merged by jenkins-bot:
[mediawiki/vagrant@master] Add support for xdebug on PHP 7.2

https://gerrit.wikimedia.org/r/502495

The change above results in the message Cannot load Xdebug - it was already loaded whenever I run a maintenance script in vagrant. Xdebug was previously added to MediaWiki vagrant in T212045: Vagrant has Xdebug no longer enabled, preventing debugging and code coverage generation, and it appears both are actually loaded.

Oh shoot, sorry about that!

I don't see xdebug available via apt for php 7.2 on my mw-vagrant install (before this patch), only xdebug 2.5.0 for the secondary php7.0 install.

I'll revert out the commit and try to work out why we're not seeing the package being discussed in https://phabricator.wikimedia.org/T212045

Change 506121 had a related patch set uploaded (by Jgleeson; owner: Jgleeson):
[mediawiki/vagrant@master] Revert "Add support for xdebug on PHP 7.2"

https://gerrit.wikimedia.org/r/506121

revert patch is here: https://gerrit.wikimedia.org/r/#/c/mediawiki/vagrant/+/506121/

Change 506121 merged by jenkins-bot:
[mediawiki/vagrant@master] Revert "Add support for xdebug on PHP 7.2"

https://gerrit.wikimedia.org/r/506121

In T220406#5134091, @Mainframe98 wrote:

The change above results in the message Cannot load Xdebug - it was already loaded whenever I run a maintenance script in vagrant. Xdebug was previously added to MediaWiki vagrant in T212045: Vagrant has Xdebug no longer enabled, preventing debugging and code coverage generation, and it appears both are actually loaded.

Was this problem seen on a clean vm instance or on an instance that had been built (or updated) with the old thirdparty/php72 repo? I'm going to guess the latter.

We generally do not add Puppet code in MediaWiki-Vagrant to remove old components as this is difficult and error prone. Issues such as the collision of old and new packages are generally left for the MediaWiki-Vagrant user to resolve manually inside an existing vm instance or more ideally by destroying the corrupt vm and building a new one. If @jgleeson's patch works as expected on a clean MediaWiki-Vagrant instance the best way forward may be to create some documentation on how to manually clean up a vm with the older apt package installed and announce that on wikitech-l to let others know how to resolve the issue if they are not willing or able to rebuild their vm from scratch.

It was the latter, I updated because of an unrelated reason (needed rMWVAe7f3fd), and after provisioning, I noticed the message.

The thing, is xdebug, and remote debugging worked just fine (as I've used it multiple times) before the patch was merged, so to me, the whole patch seems unnecessary in the first place, that's why I filed T212045 in the first place. If the patch here is a better solution, then sure, by all means, use that instead.

In T220406#5136753, @Mainframe98 wrote:

The thing, is xdebug, and remote debugging worked just fine (as I've used it multiple times) before the patch was merged, so to me, the whole patch seems unnecessary in the first place, that's why I filed T212045 in the first place. If the patch here is a better solution, then sure, by all means, use that instead.

Between the time that T212045: Vagrant has Xdebug no longer enabled, preventing debugging and code coverage generation was closed and now MediaWiki-Vagrant followed production's move from using the thirdparty/php72 repo to T216712: Switch PHP 7.2 packages to an internal component. This new repo does not have the php-xdebug package that was added to the prior repo in T212757: Please import php-xdebug to apt.wm.o thirdparty/php72.

The "proper" fix is probably to ask for the equivalent of T212757: Please import php-xdebug to apt.wm.o thirdparty/php72 done again in the new repo by an SRE rather than forcing every VM to compile the PECL package manually.

Ah, I incorrectly assumed, that because T216712 wasn't marked as resolved yet, that that hadn't happened yet. I've filed T221923 for that. However, as SRE is off-site this week according to wikitech.org, temporarily reverting https://gerrit.wikimedia.org/r/506121 might help those currently without xdebug.

Looks like we now have a package in apt.wikimedia.org for xdebug for php7.2 (T221923) and no longer need to build it as part of the provisioning steps.

It looks like this stops working when updating PHP 7.2 to the latest php7.2 package (Version: 7.2.24-1+0~rOMWC2019102616b8.31+debian9~1.gbpbbacde+wmf1) from apt.wikimedia.org/wikimedia

I had to install xdebug 2.8.0 via PECL to get it back.

This tripped us up again today. Looks like we need to upgrade the apt.wikimedia xdebug package inline with the latest version of PHP in same repo.

This doesn't work for me either on the mediawiki-vagrant box.

XDebug: 2.7.0
IDE: VSCode

The vagrant box comes installed with Xdebug 2.7.0. When debugging, threads appear to die and then it tries to reconnect again,

Logs from xdebug

[30414] <- run -i 3
[30414] Log closed at 2020-02-09 15:23:57
[30414]
[30414] Log opened at 2020-02-09 15:23:57
[30414] I: Checking remote connect back address.
[30414] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[30414] I: Checking header 'REMOTE_ADDR'.
[30414] I: Remote address found, connecting to 10.0.2.2:9000.
[30414] I: Connected to client. :-)
[30414] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/w/index.php" language="PHP" xdebug:language_version="7.2.22-1+0~20190902.26+debian9~1.gbpd64eb7+wmf1" protocol_version="1.0" appid="30414"><engine version="2.7.0"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2019 by Derick Rethans]]></copyright></init>
[30414]
[30414] <- breakpoint_list -i 1
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="1"></response>
[30414]
[30414] <- breakpoint_list -i 2
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="2"></response>
[30414]
[30414] <- run -i 3
[30414] Log closed at 2020-02-09 15:23:57
[30414]
[30414] Log opened at 2020-02-09 15:23:57
[30414] I: Checking remote connect back address.
[30414] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[30414] I: Checking header 'REMOTE_ADDR'.
[30414] I: Remote address found, connecting to 10.0.2.2:9000.
[30414] I: Connected to client. :-)
[30414] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/w/index.php" language="PHP" xdebug:language_version="7.2.22-1+0~20190902.26+debian9~1.gbpd64eb7+wmf1" protocol_version="1.0" appid="30414"><engine version="2.7.0"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2019 by Derick Rethans]]></copyright></init>
[30414]
[30414] <- breakpoint_list -i 1
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="1"></response>
[30414]
[30414] <- breakpoint_list -i 2
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="2"></response>
[30414]
[30414] <- run -i 3
[30414] Log closed at 2020-02-09 15:23:57
[30414]
[30414] Log opened at 2020-02-09 15:23:57
[30414] I: Checking remote connect back address.
[30414] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[30414] I: Checking header 'REMOTE_ADDR'.
[30414] I: Remote address found, connecting to 10.0.2.2:9000.
[30414] I: Connected to client. :-)
[30414] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/w/index.php" language="PHP" xdebug:language_version="7.2.22-1+0~20190902.26+debian9~1.gbpd64eb7+wmf1" protocol_version="1.0" appid="30414"><engine version="2.7.0"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2019 by Derick Rethans]]></copyright></init>
[30414]
[30414] <- breakpoint_list -i 1
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="1"></response>
[30414]
[30414] <- breakpoint_list -i 2
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="2"></response>
[30414]
[30414] <- run -i 3
[30414] Log closed at 2020-02-09 15:23:58
[30414]
[30414] Log opened at 2020-02-09 15:23:58
[30414] I: Checking remote connect back address.
[30414] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[30414] I: Checking header 'REMOTE_ADDR'.
[30414] I: Remote address found, connecting to 10.0.2.2:9000.
[30414] I: Connected to client. :-)
[30414] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/w/index.php" language="PHP" xdebug:language_version="7.2.22-1+0~20190902.26+debian9~1.gbpd64eb7+wmf1" protocol_version="1.0" appid="30414"><engine version="2.7.0"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2019 by Derick Rethans]]></copyright></init>
[30414]
[30414] <- breakpoint_list -i 1
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="1"></response>
[30414]
[30414] <- breakpoint_list -i 2
[30414] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="2"></response>

Upgrading to Xdebug 2.9.2, via pecl fixed the issue. Not sure which change in Xdebug fixes the issue.

I've run into the same issue, but didn't get the same information in the xdebug logs; @abi_, did you do anything special to get these logs?

In any event, I've filed T244716: Update php-xdebug to 2.9.2 in apt.wm.o component/php72 to get the XDebug package updated.

XDebug 2.7.0 is broken horribly with MediaWiki-Vagrant, see T247587: XDebug makes requiring files unreasonably slow and affects open file limit (same issue @abi mentions above). 2.7.2 works fine. We need this ASAP.

Reframed the task since it seems the PECL route was discarded (probably for the better). OTOH we are about to support PHP 7.4 in MediaWiki, and testing that would require at least 2.8.0. So I wonder if it's better to just merge this into T244716: Update php-xdebug to 2.9.2 in apt.wm.o component/php72?

I have added a couple tasks that are related to Xdebug 2.7.0 having bug.

For T234418, I have identified the upstream patch and got it added to our Debian package.
T247587 is fixed in 2.7.2. Potentially the patches can be picked as well.

But at this point, I guess it is probably easier to just upgrade our package from 2.7.0 straight to 2.7.2. Unless serviceops prefers to manually cherry pick all the fix.

For reference php-xdebug is on our apt component component/php72.

What can be done to get this moving?

Change 623015 had a related patch set uploaded (by Dduvall; owner: Dduvall):
[mediawiki/vagrant@master] Warn users that xdebug 2.7.0 is broken

https://gerrit.wikimedia.org/r/623015

Change 623015 merged by jenkins-bot:
[mediawiki/vagrant@master] Warn users that xdebug 2.7.0 is broken

https://gerrit.wikimedia.org/r/623015

Change 850084 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/vagrant@master] Revert "Warn users that xdebug 2.7.0 is broken"

https://gerrit.wikimedia.org/r/850084

Change 850084 merged by jenkins-bot:

[mediawiki/vagrant@master] Revert "Warn users that xdebug 2.7.0 is broken"

https://gerrit.wikimedia.org/r/850084