I'm having a problem with xdebug not stopping at breakpoints when using remote debugging (everything is fine when running scripts via the command line). It will break at the first line of the program, then exit, not catching any breakpoints.

It used to work fine, until I switched over to using MacPorts for Apache and PHP. I've tried re-compiling it several times (with several versions), but no dice.

I'm using PHP 5.3.1 and Xdebug 2.1.0-beta3

I've also tried at least 3 different debugging programs (MacGDBp, Netbeans and JetBrains Web IDE).

My php.ini settings look like:

[xdebug]
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_m开发者_开发技巧ode=req
xdebug.remote_port=9000
xdebug.remote_host=localhost
xdebug.idekey=webide

And when I log the debugger output, setting a breakpoint looks like this/;

<- breakpoint_set -i 895 -t line -f file:///Users/WM_imac/Sites/wm/debug_test.php -n 13 -s enabled -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="895" state="enabled" id="890660002"></response>

When run, the debugger will get the context of the first line of the application, then send the detach and stop messages.

However, this line is output when starting the debugger.

<- feature_get -i 885 -n breakpoint_types -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_get" transaction_id="885" feature_name="breakpoint_types" supported="1"><![CDATA[line conditional call return exception]]></response>

Does 'line conditional call return exception' mean anything?

---

I had this problem and took me ages to find the answer.

In your debug config, in the server area, click Configure, go to Path Mapping, click the path that's there and click edit, change to Path in file system and navigate to the correct file.

Done.

---

I had the same problem, and finally I found that my php.ini was missing these two important settings:

xdebug.remote_autostart = "On"
xdebug.remote_enable = "On"

Then it worked perfectly.

---

XDebug works fine in my Ubuntu Lucid box using NetBeans, and i do have the zend_extension line in my php.ini (/etc/php5/apache2/php.ini).

I'm using netbeans 6.9 and PHP 5.2 with xdebug 2.0.4-2

I'm pasting the relevant lines here, hope it helps:

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

[debug]
; Remote settings
xdebug.remote_autostart=on
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"

; General
xdebug.auto_trace=off
xdebug.collect_includes=on
xdebug.collect_params=off
xdebug.collect_return=off
xdebug.default_enable=on
xdebug.extended_info=1
xdebug.manual_url=http://www.php.net
xdebug.show_local_vars=1
xdebug.show_mem_delta=0
xdebug.max_nesting_level=100
;xdebug.idekey=

; Trace options
xdebug.trace_format=0
xdebug.trace_output_dir=/tmp
xdebug.trace_options=0
xdebug.trace_output_name=crc32

; Profiling
xdebug.profiler_append=0
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_dir=/tmp
xdebug.profiler_output_name=crc32

---

from http://xdebug.org/docs/install , "You should ignore any prompts to add "extension=xdebug.so" to php.ini — this will cause problems."

so, this fixed it for me :

in the config file , where you load the xdebug extension ( for me , for the CLI version of php , that was /etc/php5/cli/conf.d/xdebug.ini ) - dont specify

extension=xdebug.so

instead , use

zend_extension=/path/to/xdebug/module/xdebug.so

( for me , this was something like /usr/lib/php5/(...)/xdebug.so )

Use locate xdebug.so to find the location.

---

I have had the same issue, the solution for me was to have the local code on the same path as the remote code.

Example

On the webserver the code was located on the path: /var/www/dev01/app_name

Locally the code was located in my home directory: /home/me/projects/app_name

This configuration caused my IDE (Eclipse and Komodo) to fly straight past the breakpoints.

Changing the local path from /home/me/projects/app_name to /var/www/dev01/app_name fixed the issue. Using sshfs to locally mount the remote filesystem makes it even easier.

---

I just experienced something similar to safl's comment above using Komodo but not sure if it's related:

I had xdebug set up using zend_extension with Komodo and it works perfectly, can set breakpoints and xdebug_break(), but only some files. Others did not work.

The solution was in the way that the mapping of the remote and local paths occurred. Turns out that Komodo is doing a case-sensitive compare on path name, so my mapping didn't quite match. Files that the debugger opened from stepping through were on the right path, but files that I opened through the ide had an uppercase driveletter which apparently caused Komodo to overlook.

---

I tried all these solutions to no avail. I was confused because XDebug worked for one of my projects but not this new one. After stumbling around comparing configuration properties, I realized that on

Project Properties > Sources > Web root:

the value was set to a default value on the new project, but set to webroot on the existing project. So, I browsed to the project's webroot and set that value. I tested it and, bada-bing, it worked.

---

Are you totally sure you're not loading the Xdebug via extension=xdebug.so? Xdebug will load if this line appears in your php.ini (i.e. it appears in phpinfo() output, etc.) but breakpoints do not work if loaded in this way. (It will even connect to debugger clients, and accept breakpoints--they just never get triggered.)

I suggest you comment out the zend_extension line and see if it's still loaded--you might think you're loading Xdebug via /etc/php5/conf.d/xdebug.ini, for example, but something has added it to /etc/php5/apache2/php.ini behind your back.

See this question & answer for more information.

---

I ran into this same exact thing and was banging my head against it for a while. At some point I had also added ZendDebugger.so to my PHP.ini and that was what was breaking Xdebug. Commenting out the ZendDebugger.so line in my php.ini fixed it.

If you're not using ZendDebugger, you might just start disabling other Zend extensions and see if it's another extension causing the conflict.

---

I use Eclipse and also looked for a while. All things in php.ini have been right.

At the end, I found out, that in Eclipse the debugger was set so ZEND-Debugger. After I changed it to XDEBUG it worked fine.

Regards Joerg

---

I am also having the same problem. i got the solution that to load the dll file we should use zend_extension.

zend_extension=php_xdebug-2.5.5-5.6-vc11.dll 

Rest configuration will be

xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

---

Could you provide complete session log while trying to debug with Web IDE?

BTW when using Web IDE you typically don't need to set xdebug.idekey=webide since ide key is automatically assigned via url parameter.

---

I hit into that from time to time and have never been able to find out the real cause of the issue.

I usually resolve by,

1. Placing more breakpoints at the client code constructing the instances and loading the classes (as it seems like XDebug will ignore some breakpoints due to class-loading issues). You can learn and realize where these locations are by doing some step-ins.

2. Check the source paths of the dependencies. XDebug picks up these files by their full paths, you can see how your IDE addresses them at your breakpoint panel.

---

In my case, the problem was happening in only one project (I was only able to break using xdebug_break), while in the other projects was working fine.

It was fixed editing the file: nbproject/private/private.properties: And set:

copy.src.files=false

When I created the project I selected "copy sources" option by mistake. Then I manually moved the project and edited its source path (at the "nbproject/project.properties" file), which the debugger was still looking for the old path (set in copy.src.target).

So technically, other way to fix this DEBUG problem is to recreate the nbproject directory (by removing it and creating the project again). I guess the debugger should work fine with the "copy" option enabled (as I never use it).

I hope this can help.

---

I had a similar issue and came across a post to fix the problem. My html form (testform.html) was calling a php script (runQuery.php) and Netbeans could not break at the set break points in my runQuery.php

After checking all the configuration settings in php.ini and Netbeans by searching on forums like this one, I discovered that netbeans will only break on the break points if the Index file for the project is a PHP file. This is very important otherwise you will spend hours trying to figure out why break points are not working.

In Netbeans go into the File/Project Properties/Run Configuration and check that the Index file is a PHP file. In my case I changed my index file from testform.html to testform.php and it worked, I was able to break on break points.

---

When it comes to paths, OSX file system is not case sensitive, but xdebug seems to be.

In my case everything seemed to work even though I was running the script using /proj/test.php instead of /Proj/test.php.

When xdebug (or at lest the version I currently have) is checking for breakpoints, the check is case-sensitive. If the break point is set for /Proj/test.php, but the script is run via /proj/test.php then there is no match.

I also had a similar problem with the PHP include path. The path included /proj -directory, which was wrong. Running the code worked, but since the breakpoints were set using /Proj, they were not hit.

To check if this is the problem:

• Enable logging, -dxdebug.remote_log=/tmp/remote.log
• Check the exact path in the log when breakpoints are set
• Compare the path to the PHP intepreter is using, for example: echo dirname(__FILE__) ;

---

There can also be a problem with unusual symbols in the path. For example,I was having my code located by path:

C:\[dev]\OpenServer\domains\...

And I was unable to catch anything, but after changing path problem disappeared:

C:\dev\OpenServer\domains\...

So even brackets matter.

---

I was trying to debug with PhpStorm, but it didn't stop at some breakpoints and started ignoring even more as I was trying every single solution I could find with Google.

The problem was there were multiple detached PHP processes running in the background that actually handled my requests. PhpStorm didn't stop at breakpoints because the process I was debugging wasn't receiving requests. Killing these processes solved it for me.

---

I can't comment on a post therefore this post.

The solution to my problem was a lot like pitchandtone said. Eclipce had made wrong and double path mapping items. Nevertheless I could use the relative paths (i.e. /project/folder).

---

I hate these configurations. My life was changed when I knew the lib Dephpugger.

Is a debugger to run in terminal (like ipdb for Python and byebug for Ruby). https://github.com/tacnoman/dephpugger Is very easy to use.

---

Just for a quick update on the subject I had a similar problem with my new dev setup and it was apparently a version problem : at least with PHP Version 7.1.20-1+ubuntu16.04.1+deb.sury.org+1 xdebug 2.7.1 didn't work :

it performed successfully the first request (I am on a Symfony project so it's router.php) but then when my IDE (PHPSTORM) asked it for another breakpoint it just crashed so no breakpoint log and of course my page didn't load too ^^.

I figured it out watching the log (in php.ini you can customize it with xdebug.remote_log parameter). Hopefully i rollbacked xdebug to 2.6.1 and now all is alright.

Hope it helps someone ;)

---

In my case, when I move the zend_extension item from above [xdebug] to beneath [xdebug], it works well.

;zend_extension = "D:\wamp\bin\php\php5.6.25\ext\php_xdebug-2.5.4-5.6-vc11-
x86_64.dll"
[xdebug]
zend_extension ="D:/wamp/bin/php/php5.6.25/zend_ext/php_xdebug-2.4.1-5.6-vc11.dll"

xdebug.auto_trace = On
xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.profiler_enable = On
xdebug.profiler_enable_trigger = On

---

To fix issues debugging PHP CLI,

Add environment variables to ~/.bashrc (and reload it afterwards):

export PHP_IDE_CONFIG="serverName=www.yourservernameurl.com"
export XDEBUG_CONFIG="idekey=PHPSTORM"

(I use phpstorm, but you can omit the second one as needed)

---

Also make sure that the files are synchronized local and remote, otherwise your breakpoint might land in a invalid area, e.g. empty line and it won't work.

Also make sure that you have enough permissions. I tried to synchronize through NetBeans and got Permission denied

Also make sure that the URL in your browser is set correctly after you start the debugger. My nbproject folder had an old URL in it.