Remote debugging does not stop at breakpoints

Question

I have a problem with xdebug that does not stop at breakpoints when using remote debugging (everything is fine when running scripts through the command line). It will break in the first line of the program, and then exit, and will not catch breakpoints.

It worked fine until I switched to using MacPort for Apache and PHP. I tried recompiling it several times (with multiple versions), but without the dice.

I am using PHP 5.3.1 and Xdebug 2.1.0-beta3

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

My php.ini settings look like this:

[xdebug] xdebug.remote_enable=1 xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_port=9000 xdebug.remote_host=localhost xdebug.idekey=webide 

And when I register 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>

At startup, the debugger will receive the context of the first line of the application, then send disconnect and stop messages.

However, this line is displayed when the debugger starts.

<- 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>

Is there a conditional call exception to a conditional call? mean anything?

Answer 1

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

In your debug configuration in the server area, click "Configure", go to "Display Routes", click the path that is there, and click "Edit", select "Path" in the file system and browse to the desired file.

Done.

Answer 2

I had the same problem and finally I found that in my php.ini these two important parameters were missing:

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

Then it worked perfectly.

Answer 3

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

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

I am inserting the relevant lines here, hope this 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 

Answer 4

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

So this fixed it for me:

in the configuration file where you download the xdebug extension (for me, for the CLI version of php version, which was / etc / php 5 / cli / conf.d / xdebug.ini) - do not specify

extension = xdebug.so

use

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

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

Answer 5

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

Example

On the web server, the code was on the path: /var/www/dev01/app_name

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

This configuration made my IDE (Eclipse and Komodo) fly right past the control points.

Changing the local path from /home/me/projects/app_name to /var/www/dev01/app_name fixes the problem. Using sshfs to mount the remote file system locally makes it even easier.

Answer 6

I just experienced something similar to the safl comment above using Komodo, but not sure if this is related:

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

The solution was such that a comparison of remote and local paths occurred. It turns out that Komodo is doing case-sensitive matching by path name, so my matching didn't quite match. The files that the debugger opened from the transition were on the right path, but the files that I opened through ide had an uppercase letter, which apparently caused Komodo.

Answer 7

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

Project Properties> Sources> Network Root:

the value was set to default value in the new project, but set to webroot in the existing project. So, I looked at the project website and set its value. I tested it and, bad bing, it worked.

Answer 8

Are you completely sure you are not loading Xdebug through extension=xdebug.so ? Xdebug will load if this line appears in your php.ini (i.e. it will appear on the output of phpinfo() , etc.), but breakpoints do not work if loaded in this way. (It will even connect to the debugger clients and accept breakpoints - they just don't start.)

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

See this question and answer for more details.

Answer 9

I came across this exact thing and for a while banged my head on it. At some point, I 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, she fixed it.

If you are not using ZendDebugger, you can simply disable the other Zend extensions and see if this caused another conflict extension.

Answer 10

I use Eclipse and also searched for a while. All things in php.ini were correct.

In the end, I found out that in Eclipse the debugger was installed like this ZEND-Debugger . After I changed it to XDEBUG , it worked fine.

Relations Jörg

Answer 11

I have the same problem. I got the solution that we should use zend_extension to load the DLL file.

 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 

Answer 12

Can you provide a complete session log when trying to debug using the Web IDE?

By the way, when using the web IDE, you usually do not need to set xdebug.idekey = webide, since the ide key is automatically assigned using the url parameter.

Answer 13

I crashed into this from time to time and could never find the real cause of the problem.

I usually allow

• Placing more breakpoints in client code that instantiates and loads classes (because XDebug ignores some breakpoints due to problems loading classes). You can find out and understand where these locations are by following some steps.

• Check the source dependency paths. XDebug collects these files by their full paths, you can see how your IDE accesses them in the breakpoint panel.

Answer 14

In my case, the problem occurred only in one project (I was able to break only with xdebug_break), while in other projects it worked fine.

Fixed editing the file: nbproject / private / private.properties : And install:

 copy.src.files=false 

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

So technically, another way to fix this DEBUG problem is to recreate the nbproject directory (deleting it and creating the project again). I think the debugger should work fine with the "copy" option turned on (since I never use it).

Hope this helps.

Answer 15

I had a similar problem and ran into a message to fix this problem. My html form (testform.html) called the php script (runQuery.php) and Netbeans could not break the set breakpoints in my runQuery.php

After checking all the configuration parameters in php.ini and Netbeans by searching forums like this, I found that netbeans will only break into breakpoints if the index file for the project is a PHP file. This is very important, otherwise you will spend hours trying to understand why breakpoints do not work.

In Netbeans, go to File / Project Properties / Run Configuration and verify 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 the breakpoints.

Answer 16

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

In my case, everything seemed to work, although I used a script using / p roj / test.php instead of / P roj / test.php,

When xdebug (or, as far as possible, I currently have a version) checks for breakpoints, the check is case sensitive. If the breakpoint is set for / Proj / test.php, but the script is run through /proj/test.php, then there is no match.

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

To check if this problem is:

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

Answer 17

There may also be a problem with unusual characters along the way. For example, I had code located along the path:

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

And I couldn’t catch anything, but after the problem with changing the path disappeared:

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

So even brackets matter.

Answer 18

I tried to debug PhpStorm, but it did not stop at some breakpoints and started to ignore even more as I tried to find every solution I could find on Google.

The problem was in the background , several separate PHP processes were running that actually handled my requests. PhpStorm did not stop at breakpoints because the process I was debugging did not receive requests. Killing these processes resolved this for me.

Answer 19

I can not comment on the post, so this post.

The solution to my problem was very similar to the voice. Eclipce has done the wrong and double ways. However, I could use relative paths (i.e. / Project / folder).

Answer 20

I hate these configurations. My life changed when I found out about Debpugger.

The debugger runs in the terminal (e.g. ipdb for Python and byebug for Ruby). https://github.com/tacnoman/dephpugger Very easy to use.

Answer 21

Just to quickly update the subject, I had a similar problem with my new dev installation, and this was obviously a version problem: at least with PHP version 7.1.20-1 + ubuntu16.04.1 + deb.sury.org + 1 xdebug 2.7 .1 does not work:

it successfully completed the first request (I am on the Symfony project, so router.php), but then when my IDE (PHPSTORM) requested another breakpoint from it, it just crashed, so the breakpoint log and of course mine the page also didn’t load ^ ^.

I realized this by looking at the log (in php.ini you can configure it using the xdebug.remote_log parameter). I hope I rolled back xdebug to version 2.6.1, and now everything is in order.

Hope this helps someone;)

Answer 22

In my case, when I move the zend_extension element from above [xdebug] to the area below [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