Ddev: PHPStorm/Xdebug 2.8 (ddev v1.12): Xdebug stops on function definition in addition to breakpoint

[karlshea]

Describe the bug
PhpStorm or xdebug is breaking on function signatures instead of breakpoints.

To Reproduce
Steps to reproduce the behavior:

1. Create new ddev project with xdebug enabled containing these files:

index.php

<?php

print '<h1>index.php</h1>';

function test() {
  return '<h2>test function</h2>';
}

include_once './include.inc';

print test();
print includeTest();

include.inc

<?php

function includeTest() {
  return '<h2>include.inc</h2>';
}

1. Set a breakpoint inside test(), and one inside includeTest()
2. Enable Xdebug session in web browser and load page.
3. PhpStorm stops on the include_once line.
4. Hit "Resume"
5. PhpStorm stops on the includeTest() function signature.
6. Hit "Resume"
7. Breakpoint inside test() is triggered.
8. Hit "Resume
9. Breakpoint inside testInclude() is triggered.

Expected behavior
Breakpoint hits where set.

Screenshots
If applicable, add screenshots to help explain your problem.

Version and configuration information (please complete the following information):

• Host computer OS and Version: macOS Catalina 10.15.1
• Docker 19.03.4
• ddev v1.12.0
• config.yaml contents for the misbehaving project

APIVersion: v1.12.0
name: xdebug
type: php
docroot: ""
php_version: "7.2"
webserver_type: nginx-fpm
router_http_port: "80"
router_https_port: "443"
xdebug_enabled: true
additional_hostnames: []
additional_fqdns: []
nfs_mount_enabled: false
provider: default
omit_containers: [dba, db]
use_dns_when_possible: true
timezone: ""

• Do you have any custom configuration (nginx, php, mysql) in the .ddev folder? No.

Additional context
I also tried updating php-xdebug in the web-build Dockerfile as suggested in Slack, but that didn't change the behavior.

[rfay]

What a great issue, thanks so much for your care in describing this. You deserve an award for best-written-issue of the month. Thanks.

I can recreate this with PHPStorm using your instructions; it also stops on the include_once at line 9 of index.php.

I tried with vscode and had no trouble, so to me that points to a PHPStorm problem with XDebug 2.8...

I did try with latest PHPStorm EAP, PhpStorm 2019.3.1 Preview (Build #PS-193.5662.16, built on December 5, 2019) and it had the same issue.

I think it's probably this bug in PHPStorm: https://youtrack.jetbrains.com/issue/WI-50152 - Could you please follow up in that bug and help them get it sorted out? You sure did a great job here.

Also reported in xdebug queue at https://bugs.xdebug.org/view.php?id=1727

[karlshea]

❤️Thanks so much! My initial hunch that it was something to do with module_load_include() since what I was trying to debug was happening in an .inc file, but I don't think including files is the issue.

I'll follow up there.

[rfay]

The maintainer of XDebug points out that this is a feature in https://twitter.com/derickr/status/1204864073252376610 see https://derickrethans.nl/breakpoints.html - but I don't think he's understanding the impact on folks who are debugging with PHPStorm.

[rfay]

Workarounds that people have used:

1. Ignore the problem and just live with the fact that it stops at the top of a function where there is a breakpoint.
2. Pin the previous version's web container in your .ddev/config.yaml: webimage: drud/ddev-webserver:v1.11.0 - Note that if you forget about this it will likely cause trouble in the future. A quick review of the commits to the webserver container since v1.11.0 says that although there were a few bugfixes and updates, the changes of a temporary rollback here won't affect many people.

[donquixote]

If it helps, here is the workaround that works for me, also mentioned in the PhpStorm issue:

In the meantime, a workaround is to manually add conditions into the break point. E.g. are the variables from function parameters defined?
Not very convenient, but still better than the train of thought disruption when stopping on a function definition.

https://youtrack.jetbrains.com/issue/WI-50152#focus=streamItem-27-3879179.0-0

[rfay]

From the monthly XDebug update:

Breakpoint Resolving
In the May update I wrote about resolving breakpoints. This feature will try to make sure that whenever you set a breakpoint, Xdebug makes sure that it also breaks. However, there are currently two issues with this: 1. breaks happen more often than expected, and 2. the algorithm to find lines is really slow. I am addressing both these problems by using a similar trick to the one Nikita suggested for speeding up code coverage analysis. This work requires quite a bit of rewrites of the breakpoint resolving function, and hence this is ongoing. I expect this to cumulate in an Xdebug 2.9.1 release during January.

[rfay]

The xdebug maintainer is requesting verification of his fix:

https://bugs.xdebug.org/view.php?id=1727

This is now fixed in the xdebug_2_9 branch in GIT. It would be lovely if you could try this out before I put it in a release!

[rfay]

xdebug 2.9.1 has been released with this fix in it.

I'll try to figure out how to do either an edge release or a point release to fix this for people when this makes it into the package system (deb.sury.org)

[rfay]

This is fixed in (released) ddev v1.12.2, now in homebrew, shortly in chocolatey. It will also be fixed on master branch in #2035 , which should go in today, which will be followed by an alpha release of v1.13.0-alpha2. https://github.com/drud/ddev/releases/tag/v1.12.2

Enormous thanks go to @derickr (maintainer of Xdebug) and @oerdnj, who runs outstanding and essential deb.sury.org Debian packaging.