views:

1421

answers:

7

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 serveral 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_mode=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?

+1  A: 

Hello ,

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 )

zm0
I already am using zend_extension. Thanks for the insight, though.
Bryan M.
Are you sure there isn't an extension=xdebug.so *somewhere* in the PHP configuration? I had both extension=xdebug.so and zend_extension=/path/to/xdebug.so and for some reason it was taking extension=xdebug.so, which loads the extension, but breakpoints don't work.
mjs
I double checked. Only using zend_extenstion. Again, the problem here is with breakpoints when running through a web browser. Everything works normally with CLI scripts or PHPUnit.
Bryan M.
I'm sure it is just a typo on SO, but check the spelling of "zend_extension" in the PHP file - it would be a shame it that was the cause.
Oddthinking
A: 

Hello,

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.

ksafonov
Full log output here: http://pastie.org/866632. The debugger stopped on the first line, and ignored all other breakpoints.
Bryan M.
Logs show that IDE is trying to put breakpoint to the file '/Users/WM_imac/Sites/wm/debug_test.php'. Does such a file exist, or real debug_test.php has different location?
ksafonov
A: 

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.

yclian
A: 

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.

mjs
A: 

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
axel_c
A: 

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.

safl