Xdebug ignores breakpoints

Question

I am currently trying to get Xdebug to work on our development server. As client I am using netbeans and the connection so far works without problems. But when I try to set a breakpoint within netbeans it is just getting ignored.

And yeah, I already googled for hours and also found some questions here that perfectly fit my description: SO 1 SO 2

But this does not seem to solve it for me. The Xdebug module is loaded via zend_extension=path/to/xdebug. so in the

/etc/php5/conf.d/xdebug.ini

I also looked at the php5/apache and php5/cli php.ini to make sure it is not loaded with extension= somewhere there. I also checked the "additional .ini files parsed" found by phpinfo() and it seems to be nowhere else loaded.

By executing php -m I can see the loaded Xdebug module in

[PHP Modules]

and in

[Zend Modules]

Not sure if this indicates that it is still loaded twice or if it is fine like that? Still if I remove the zend_extension=/path/to/xdebug.so from the conf.d/xdebug.ini it is also no longer loaded. So I really assume it is only loaded there.

If I set the remote_log option is see that Netbeans is trying to set something:

<- breakpoint_set -i 452 -t line -s enabled 
   -f file:///http:/development.xxx.de/users/itsame/index.php -n 15
-> <response xmlns="urn:debugger_protocol_v1"
    xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" 
          transaction_id="452" state="enabled" id="258870001">   
    </response>

But it seems to have no effect (looks pretty much the same like in the other SO questions I have posted above. But if i do a manual xdebug_break() inside the php code it handels it properly.

PHP Version is 5.2.6 and Xdebug is 2.1. Any suggestions where I could have a look next?

Answer 1

It looks like there is something wrong with the path to the file containing the breakpoint.

<- breakpoint_set -i 452 -t line -s enabled 
   -f file:///http:/development.xxx.de/users/itsame/index.php -n 15 ->

I've had a similar problem with Eclipse. Only my breakpoints in the index file were accepted and breakpoints in other files—that were included in the index—were ignored.

I looked in the remote_log file and saw the following:

<- breakpoint_set -i 260 -t line 
   -f file:///~jeroen/workspace/fieg/wp-content/plugins/fieg/fieg.php -n 22-> 
<response xmlns="urn:debugger_protocol_v1" 
   xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" 
   transaction_id="260" id="48060002"></response>

I noticed that the path for the breakpoint was all wrong. It turned out that I had to setup Port Mapping in Eclipse. After setting the correct mapping the breakpoints started working. Also my remote_log now shows the correct path:

<- breakpoint_set -i 333 -t line 
   -f file:///Users/jeroen/Workspace/fieg/wp-content/plugins/fieg/fieg.php -n 12->     
<response xmlns="urn:debugger_protocol_v1" 
   xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" 
   transaction_id="333" id="48080005"></response>

I'm not sure if there is an equivalent of the Eclipse Port Mapping configuration in Netbeans, but hopefully I pointed you in the good direction.

Answer 2

For me the problem was "Project properties > Source > Web Root:" was not set (it had a default " as its value).

After setting it to be my web root on disk, the breakpoints started working.

Answer 3

In your php.ini file, set this directive:

report_zend_debug = 1

I hope this help someone?

Answer 4

Go to: Project > Properties > Run Configuration > Advanced (button)

Remove all the mappings from the "Path Mapping" if you are not using Xdebug for remote debugging. This would help to fix this issue.

Answer 5

The question mentioned that the xdebug.ini file exists, but does not report its contents. My default installation's file only included:

zend_extension=/usr/lib/php5/20100525/xdebug.so

But in order for debugging to actually happen, it must be enabled. Add this line:

xdebug.remote_enable=1

Then phpinfo() will report a functioning xdebug:

Answer 6

I came across this post trying to solve my xdebug problem in eclipse not breaking at break points for a web application. I found the comments herein very useful. Also, this post http://www.devside.net/wamp-server/netbeans-waiting-for-connection-netbeans-xdebug-issue came in very handy to solve my issue. I just had to set the following flag in my relevant php.ini.

xdebug.remote_enable=1

xdebug would continuously wait on the session but after setting the remote debug flag the session wait issue, breaking point issue as well the xdebug log file that I had defined also started logging transactions.

Answer 7

Yet another possible solution, the only one that worked for me, after trying everything in this post and in many others...

I'm debugging a PHP project through XDEBUG on Eclipse Neon on Windows. The source is remote Linux, mounted locally as a drive through SFTP. It's probably my own fault that this isn't set up correctly...

In Eclipse, right-click your project, then select Configure, then Add PHP Support. Immediately, the DLTK indexing started; before that it wouldn't start no matter what.

Then I had to open my source and set the breakpoints through Remote File Explorer. I hope this helps someone.

Answer 8

I had the same problem: Eclipse breakpoints did not work, xdebug_break() did work. My problem were spaces in the path:

<- breakpoint_set -i 1323 -t line -f file:///Users/admin/Documents/projects/something/path%2520with%2520space/web/index.php -n 223
-> 
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="1323" id="385680235"></response>

After changing the path to something without spaces the breakpoints in Eclipse worked fine.

Answer 9

Solved! When creating a new project in NetBeans, I first set the root folder of the project to the WordPress theme folder of my WordPress site. So instead, I created a new project with the root of it being the root of the entire WordPress site rather than just its theme, and the breakpoints started to work. Woohoo!

Answer 10

in my case:

use system default php.ini configuration 

was not selected in the PHP Executable general settings