Saturday, October 3, 2009

How to Debug PHP with Vim and XDebug on Linux

How to Debug PHP with Vim and XDebug on Linux

Here is the scenario: You have multiple developers logged into a Linux server which is running Apache and PHP using Vim to write PHP code. They’re using error_log and echo statements to debug their code. It takes forever, it’s tedious and can result in bugs from forgotten debug statements. You stare enviously at .NET programmers with fancy debuggers (while you snicker knowing that you edit 10x faster with Vim anyways). But still, you know there has to be a better way.

There is.

Here’s how it works. You’re coding away in vim. You hit F5; Vim waits for a connection from the PHP server. You refresh the PHP page you’re working on. It attempts to contact Vim — connection successful. You are launched into a debugging session right inside Vim. You can step into, over, and out of statements, eval statements, get all variables in context, get and set properties, remove and set breakpoints, all on the fly. Finally, some real programming tools.

The environment: Vim

First, we need to make sure vim is compiled correctly.

Type :version in your Vim and check the features section. If you have +python and +signs, you’re good to go. Skip ahead to the next section.

Otherwise, you need to compile from source. On Linux, download and untar the source code, and open up src/feature.h. You need to comment out the conditional statements around the +signs feature. In Vim 7.1, it looks like this:

/*

* +signs       Allow signs to be displayed to the left of text lines.

*          Adds the ":sign" command.

*/

#if defined(FEAT_BIG) || defined(FEAT_SUN_WORKSHOP) \

        || defined(FEAT_NETBEANS_INTG)

# define FEAT_SIGNS

# if ((defined(FEAT_GUI_MOTIF) || defined(FEAT_GUI_ATHENA)) \

        && defined(HAVE_X11_XPM_H)) \

    || defined(FEAT_GUI_GTK) \

    || (defined(WIN32) && defined(FEAT_GUI))

#  define FEAT_SIGN_ICONS

# endif

#endif

You need to comment out both if statements and their respective endif’s, so it looks like this:

/*

* +signs       Allow signs to be displayed to the left of text lines.

*          Adds the ":sign" command.

*/

/*#if defined(FEAT_BIG) || defined(FEAT_SUN_WORKSHOP) \

        || defined(FEAT_NETBEANS_INTG)*/

# define FEAT_SIGNS

/*# if ((defined(FEAT_GUI_MOTIF) || defined(FEAT_GUI_ATHENA)) \

        && defined(HAVE_X11_XPM_H)) \

    || defined(FEAT_GUI_GTK) \

    || (defined(WIN32) && defined(FEAT_GUI))*/

#  define FEAT_SIGN_ICONS

/*# endif

#endif*/

then cd back to the top source directory and run:

./configure --enable-pythoninterp

If on a 64-bit system or a system with a strange python installation, you may have to add --with-python-config-dir=/usr/lib64/python2.3/config to the configure string. If the configure script can’t find the config directory it will say so in the script output, but the configure won’t explicitly fail — so you have to be sure that all the python stuff is OK.

After configuration, do

make && make install

to install your newly python’d vim.

The client: Debugger.vim (and Debugger.py)

Now that vim is ready, download the DBGp client script. Extract the two files (debugger.vim and debugger.py) to your vim plugin directory or your .vim home directory. In Vim 7.1 compiled on Linux, the default load-for-everyone plugin location is /usr/local/share/vim/vim71/plugin/, so you would put both files in that directory.

Try to run vim — if you get no errors, everything should be good. If you get an error, double check :version to make sure +python and +signs are there. If they are, post a comment here with the vi error you get. If they aren’t, the vim compilation/installation didn’t work — go back and try it again.

Now your debugging client is ready. Now let’s setup the server.

The server (engine): XDebug

Download XDebug. Download the source, compile the .so and add the following lines to your php.ini:

[Zend]

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

xdebug.remote_enable = 1

xdebug.remote_port = 9000

xdebug.remote_host = localhost

Open a file in your browser which outputs  to make sure xdebug is loaded.



Now, with your site being example.com, go to http://example.com/index.php?XDEBUG_SESSION_START=1. This will set a cookie in your browser which expires in 1 hour which tells the PHP XDebug module to try to make a connection every time a page loads to a debugging client which is listening on port 9000. The cool thing is that if it can’t make a connection, it just keeps loading the page, so there’s no issue just leaving the cookie on.

Now go back to vim and press F5. You should see a message like “waiting for a new connection on port 9000 for 5 seconds…” at the bottom of the screen. You have five seconds to now refresh the PHP page. This will create a connection between the debugger and client. Now you’re debugging. Follow the instructions in the Help window to step into, over and out of code. Press F5 to run the code until a breakpoint (which you can set using :Bp).



But what if I have multiple developers on the same machine?

No problem. Simply set g:debuggerPort in each developer’s .vimrc to get the client listening on a different port. So if you wanted one developer to connect on 9001 instead of the standard 9000, you would add this line to their .vimrc:

let g:debuggerPort = 9001

Getting the server to connect on a different port is a little trickier. You need to set a custom php.ini value (xdebug.remote_port) for each user. It works best if you’re using VirtualHost’s in Apache. Just add the following line to the VirtualHost section of your httpd.conf:

php_value xdebug.remote_port 9001

Now restart Apache and if you use that VirtualHost and that vi user, then they should connect successfully.

That’s about it

Please post any questions or suggestions you may have. I hope this helps a few of you out there who want debugging tools but don’t want to give up Vim editing. Also be sure to post any alternate methods, or any patches or improvements to the remote PHP debugger vim script, and I’ll be sure to incorporate them.

[Note: This is the first in a series of posts we'll be doing along the lines of tutorials, tools we've developed, tech commentary, and so on. Please feel free to subscribe, as well as leave any comments, thoughts or suggestions below so we can be sure to improve with each article! Thanks!]

This entry was posted on Wednesday, June 20th, 2007 at 4:18 am and is filed under Tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

69 Responses to “How to Debug PHP with Vim and XDebug on Linux”

Trenton Weir Says:

Thanks, this looks very interesting, but the link to ‘DBGp client script’ doesn’t work.

June 26th, 2007 at 6:10 pm

Sam Ghods Says:

Thanks! This has been fixed.

June 26th, 2007 at 6:15 pm

How to Debug PHP with Vim and XDebug on Linux at BetaSoft Developers Log Says:

[...] how-to-debug-php-with-vim-and-xdebug-on-linux/ [...]

July 18th, 2007 at 2:03 am

» ???vim?xdebug???php » WEB?????? Says:

[...] ???? [...]

July 19th, 2007 at 9:13 pm

Erik Schwartz Says:

This is a great tutorial — thank you very much for the effort. I run Feisty Fawn with backported php 4.3.10-10ubuntu3 and everything worked great.

The one question I have is about debugging forms. Does anyone know of a way to begin debugging a page once a form has been submitted with xdebug+vim? I currently use the Zend Client and this feature has proven extremely useful. I’m really hoping to move to an open source environment and I’ve not been able to configure Eclipse PDT, Protoeditor, or PHPEclipse to work on my machine. This seems like a great solution but I hope to discover a native form debugging capability.

Cheers and thanks again,

Erik

August 1st, 2007 at 1:49 pm

Erik Schwartz Says:

Scratch that last comment — my apologies. It’s easy enough to debug a form by submitting it the 5 second window after pressing f5 in vim.

August 1st, 2007 at 1:55 pm

Ben Giles Says:

thank you for keeping the xdebug vim script alive!

August 9th, 2007 at 8:56 am

Brownie Says:

Hey Just letting anyone know Xdebug can work as both as an extension and a zend_extension (eg. the ubuntu pecl install initially suggests you add extension=xdebug.so which works fine for profiling)..

The debugger will only work if its loaded as a zend_extension (as it is of course explained in the blog) . but I still managed to get caught!. The debugger will initially look like it was working but fail when it tries to set the breakpoint.

hope this helps someone else. Many thanks for the article

August 10th, 2007 at 4:23 am

david_kw Says:

Thanks for the tutorial and the script/configuration files. I was able to get it up and running in Windows. In the process, I made some changes and feature upgrades to the script. Things like the ability to do a get_property on a selected area and changing the EVAL_RESULT to the actual name of the property when available (there was code that was trying to do it but didn’t work for me).

I also changed the function keys to be more like FireBug and a few other user specific changes, but I could work those out if you are interested in integrating my other changes. If so, just send me an email.

August 28th, 2007 at 5:34 pm

bitlogic Says:

Hi,

Nice article.

I has just installed XDebug and the plugins without problem.

But when try to debug I’m getting this error:

(, , )

File “/home/llsousa/.vim/plugin/debugger.py”, line 1078, in debugger_run

try:

File “/home/llsousa/.vim/plugin/debugger.py”, line 928, in run

self.clear()

File “/home/llsousa/.vim/plugin/debugger.py”, line 560, in accept

serv.close()

What can be wrong?

August 31st, 2007 at 10:22 am

alessandro Says:

Hi,

thanks for this script!

I have an error after hitting F5:

waiting for a new connection on port 9000 for 5 seconds…

Connection closed, stop debugging (, AttributeE

rror(”DbgProtocol instance has no attribute ’stop’”,), )

What can I do?

Xdebug is 2.0.0RC4 on ubuntu linux

September 4th, 2007 at 9:50 am

Wally Brock Says:

Works with Mac OS X as Well!

Even though the tutorial says “Linux” this also works on Mac OS X as well.

Thank you for an excellent tool!

September 10th, 2007 at 10:00 am

Thomas Koch Says:

Definitely live changing!

But I’ve some issues with Breakpoints. They doesn’t seem to work if the Breakpoint is placed in some deeper file in the stack. Wouldn’t you like to place this project somewhere in a development environment with public svn, bugtracker and mailinglist?

September 21st, 2007 at 2:53 am

Khalid -- 2bits Says:

I wrote a set of articles on debugging PHP (mainly Drupal), see Developing, tracing and Debugging Drupal, and an article on setting up xdebug DBGp for PHP on Debian/Ubuntu, as well as using vim and xdebug DBGp for debugging Drupal or any PHP application

September 30th, 2007 at 10:52 am

PHPDeveloper.org Says:

Box.net: How to Debug PHP with Vim and XDebug on Linux…

Curt Zirzow has pointed out a cool article on the Box.net ……

November 7th, 2007 at 9:46 am

developercast.com » Box.net: How to Debug PHP with Vim and XDebug on Linux Says:

[...] Zirzow has pointed out a cool article on the Box.net website about debugging your PHP applications with a combination of Vim and XDebug [...]

November 7th, 2007 at 1:59 pm

Chris Hartjes Says:

Great post as I like to use vim from time to time when Komodo pisses me off. I’m running this on OS-X and had no problems getting it run, but I couldn’t see in the debugging window what the values of the variables at that point would be like I would see in Komodo. Any tips on that?

November 7th, 2007 at 3:32 pm

What’s In Chris’ Brain: November 2007 Edition — @TheKeyboard Says:

[...] a cool article on using debugging PHP using XDebug in vim. Sometimes Komodo gets resource hungry and a quick drop into vim usually makes me feel [...]

November 7th, 2007 at 4:58 pm

Sam Ghods Says:

Chris,

Do you mean just having a watch window which displays pretty much any variable currently in the scope? That would be pretty cool… the client script doesn’t implement it currently but it shouldn’t be too hard. I think you would just have to run the get_defined_variables() PHP function after each time the debugger pauses and put the results stuff in one of the windows. I don’t have the time or Python experience to rig that up at the moment but if anyone wants to write that in and send me a diff, I’d be more than happy to incorporate it in the script and publish it on the vi plugin page.

November 8th, 2007 at 2:59 am

Travis Swicegood Says:

Running MacVim (vim 7) I had to use Andrei’s modified debugger.py file to get it working. It’s available at: http://www.gravitonic.com/blog/archives/000357.html along with some excellent slides for anyone who’s new to vim.

November 8th, 2007 at 11:27 am

Donncha’s Friday Links at Holy Shmoly! Says:

[...] linked to How to Debug PHP with Vim and XDebug on Linux. I started reading but then I realised I had to compile Vim again! I’ll stick with my [...]

November 9th, 2007 at 10:41 am

Chris Hartjes Says:

Sam,

Yes, that’s exactly what I’m talking about. In Komodo when you use their built-in support for XDebug they provide you with a small window that shows you all the variables currently in scope and their values. I find that very useful as I’m trying to wean myself off of the old print_r and echo style of debugging.

November 9th, 2007 at 11:41 am

Gavin Says:

Hey. Just wanted to point out that you can install xdebug with pecl install xdebug

On Ubuntu you might/will need to install build-essential and possibly other packages.

Gav

November 14th, 2007 at 11:52 pm

Gavin Says:

The webserver and the machine I’m typing on are two difference machines. Is that a problem?

November 15th, 2007 at 2:59 am

Sam Ghods Says:

Gavin,

Not a problem, as long as the webserver has access to your debug machine. Simply change xdebug.remote_host = , and change xdebug.remote_port = . The only problem might be that you might need to set up your router or firewall to allow and route incoming requests to port 9000 (or whichever port you choose) to your local machine. Good luck!

November 15th, 2007 at 4:25 am

Gavin Says:

Aaaah yes. Thanks, that was it. Next question





I set a breakpoint in a script inside my framework; when I debug it stops at line 1 of the first script. Pressing lands me back at line 1 of script 1. Pressing again shows me “Connection closed, stop debugging etc”. Am I doing something wrong ?

Also, I was thinking about the keys. I already have F1-F12 mapped. I tweaked debugger.vim to (only) use “d*” with * being something appropriate (although you already had some d mappings.) It might make the script less invasive.

gav

November 15th, 2007 at 5:26 am

Gavin Says:

Can I file bug reports here ?

get_property_at_cursor doesn’t handle static properties of classes e.g.

I want to see the value of

App::$route

but the watch window says

property_get: $route

.

November 15th, 2007 at 5:31 am

Gavin Says:

re the keys: earlier. I “meant” to talk about the script using

Leader d*, but my “html tags” were stripped:

d*

gav

November 15th, 2007 at 5:33 am

pa Says:

Hello, maybe it is a vim 7.0 only error, but when I press F5 in vim I get :

waiting for a new connection on port 9000 for 5 seconds…

Connection closed, stop debugging (, , )

When I press enter to see the result, I get :

(, , )

File “/usr/share/vim/vim70/plugin/debugger.py”, line 1078, in debugger_run

debugger.run()

File “/usr/share/vim/vim70/plugin/debugger.py”, line 928, in run

self.protocol.accept()

File “/usr/share/vim/vim70/plugin/debugger.py”, line 560, in accept

self.stop()

Where am I wrong ? I have +signs and +python in :version, I have the extension, I have the XDEBUG_SESSION cookie too…

November 19th, 2007 at 7:24 am

dbu Says:

[this was a "bug" report, until i realized my setup was wrong. now its just a bunch of tips:]

if you want the +signs and +python on ubuntu, just do ‘apt-get install vim-python’ if you don’t want to compile it yourself.

instead of telling something of a timeout, my vim tells me “DbgProtocol instance has no attribute ’stop’” if nothing connected to it for 5 seconds.

if your phpinfo tells you “XDEBUG NOT LOADED AS ZEND EXTENSION” you did not include the .so as zend_extension (which is required, as mentioned above).

xdebug.remote_enable must be set to 1 or on, it defaults to off.

(i was confused because xdebug.remote_host defaults to localhost, xdebug.remote_port to 9000 if not set)

November 20th, 2007 at 9:03 am

????? » Blog Archive » ?vim???php??????php???? Says:

[...] ????phpEclipse?????????????????????????zend studio????Eclipse??????????????????????zend studio???????????????????????vim??????????????????????? ?http://tech.blog.box.net/2007/06/20/how-to-debug-php-with-vim-and-xdebug-on-linux/? [...]

November 30th, 2007 at 9:46 am

N. Says:

Don’t forget to set

xdebug.remote_handler = dbgp

otherwise you will get a error.

December 1st, 2007 at 2:27 am

Nasko Says:

Nice article, Sam! Thank you!

I can confirm this setup works perfectly under Window XP w/ Python 2.4, Vim 7.0 (gVim), Xdebug 2.0.2. However, both debugger.vim and debugger.py files need to be modified slightly:

- debugger.py:

1) In DebugUI::init around line 440 modify the path to self.sessfile - by default it is set to ‘/tmp’ and obviously this will not work in WinXP

2) Apply the modifications refferenced by Kevin Dahlhausen in the comments to Khalid’s post here: Modification #1 and Modification #2

debugger.vim:

Around line 124 modify (if necessary) the path to debugger.py. In my case I had to change ‘$HOME/.vim/plugin’ to ‘$HOME/vimfiles/plugin’, or Vim complained about not being able to locate debugger.py

I have one question though: when I try to eval a variable or get the whole scope I’m not getting the values of multi-dimensional arrays. If I have $messages[0][key1], $messages[0][key2], etc. I only get this:

/{{{1/ => eval: $messages

$command = ‘eval’;

EVAL_RESULT = (array) ; /{{{2/

EVAL_RESULT = (array)

/}}}2/

/}}}1/

I have to explicitly type the path to the index I’m interested in as in:

eval: $messages[0]['Recipient']['Photo']

The problem is more often than not I don’t know the exact structure of variables that I want to debug.

Is there anything I may be missing? I’d be thankful for every hint that could help me out!

January 26th, 2008 at 9:07 am

Nasko Says:

Regarding my previous comment: I noticed the instructions in the comments in debugger.vim. I increased the debuggerMaxDepth to 10 and was able to retrieve all values from the array. The only issue left is I’m not able to see the array keys. I get a result like this:

EVAL_RESULT = (array) ; /{{{3/

EVAL_RESULT = (array) ; /{{{4/

EVAL_RESULT = (string) ‘6′;

EVAL_RESULT = (string) ‘3′;

EVAL_RESULT = (string) ‘5′;

EVAL_RESULT = (string) ‘1′;

EVAL_RESULT = (string) ‘0′;

/}}}4/

EVAL_RESULT = (array) ; /{{{4/

EVAL_RESULT = (string) ‘Inbox’;

Is there any setting I could change in order to get array keys as well?

Thank you!

January 26th, 2008 at 9:43 am

ruslanix Says:

Hi!

I try this script for MS Windows.

I have some problem to run this plugin.

If interested here i describe some problem and solution:

errors occurred because this script was written to linux.

And on windows you should do some changes

At vim startrup error: ‘Can’ find debugger.py’

put debugger.py to $VIMRUNTIME/plugin directory

After starting debuggin, error : ‘can’t open session file’

go to line 442 at debugger.py and change self.sessfile to file suit for you.

When press ‘Setp into, F2′, error: ‘wrong buffre name /….’

you must change in all lines code from getAttribute(’filename’)[7:] to getAttribute(’filename’)[8:]

By;)

February 2nd, 2008 at 4:34 pm

PHP, VIM, Ubuntu, XDEBUG From the blog archives of rjmolesa Says:

[...] Xdebug and VIM XDebug and Eclipse on Windows Debugging Drupal with XDebug Tracing PHP with Xdebug Debug PHP with VIM Debug Drupal with VIM Debug Symfony with VIM Debuggin PHP on [...]

February 6th, 2008 at 10:56 am

PHP::impact ([str blog [, str comments]]) » Blog Archive » Debug PHP applications with Vim and xDebug Says:

[...] there is. Sam Ghods tells you how. Posted by phpimpact Filed in PHP, Programming, [...]

March 4th, 2008 at 5:40 pm

DaveDevelopment » Archive » 10 tools for Modern PHP Development Says:

[...] traces, profiling and code coverage analysis. Debug clients are available in many PHP IDEs and even plugins so you can debug from everybody’s favourite editor vim. [...]

March 20th, 2008 at 8:02 pm

???@??? » ????php???? Says:

[...] traces, profiling and code coverage analysis. Debug clients are available in many PHP IDEs and even plugins so you can debug from everybody’s favourite editor vim. [...]

March 21st, 2008 at 1:16 am

alexander Says:

thanks

April 26th, 2008 at 3:33 am

?vim ?debug php (use xdebug) at JohnPuPu Says:

[...] Ref. http://2bits.com/articles/using-vim-and-xdebug-dbgp-for-debugging-drupal-or-any-php-application.html How do debug php with vim and xdebug on linux [...]

May 14th, 2008 at 1:45 am

Mjaque Says:

Great article and great plugin. Thanks

I am getting an error when opening files with non-ascii characters in their paths. When opening (after F5 and refreshing browser) I get a E499 vim error (Empty file name).

The problem is that vim tries to open a file with urlencoded name (’my%20file’), which obviously does not exist.

I’ve been able to replace %20 for ‘ ‘ (escaped white character).

(Add file = file.replace(’%20′,’ ‘) at handle_init method (line 794) in debugger.py)

But (due to my lack of Python knowledge) I haven’t been able to replace other non-ascii characters (Spanish accented words �����…). Same strategy (file = file.replace(’%C3%A1′, ‘�’) produces a UnicodeDecodeError in Python.

Does anybody have the same problem? Any idea how to proceed?

Thanks

June 10th, 2008 at 12:17 pm

Joker Says:

You’d probably be better off just doing:

CFLAGS=”-D FEAT_SIGNS” ./configure –enable-pythoninterp

instead of messing with the source code to enable the FEAT_SIGNS macro.

June 10th, 2008 at 5:35 pm

Jack Says:

Thanks very much! it’s very useful

July 15th, 2008 at 1:16 am

David Damstra Says:

I am so close to getting this working. Hope you can help…

Developing on WinXP with GVIM connected via sftpdrive to the remote Ubuntu box with the website on it.

Set up php.ini for remote debugging on my local WinXP IP.

I edit the file in vim, hit F5, refresh the page in firefox. It connects, but I get the following error in gVim:

E185: Invalid buffer name: var/www/{siteName}}/htdocs/filename.php

Seems to me that its trying to map the same directory structure on my locally mapped drive (via sftp) to the one on the webserver and they don’t match.

Any ideas? Thanks for your help!

July 15th, 2008 at 2:47 pm

Derek Schrock Says:

My setup

Windows 2003 Server

Apache 2.2

PHP 5.2.5 Binary install from php.net

XDebug 2.0.3 for PHP 5.2 binary from xdebug.org

Cygwin’s Python 2.5.1

Custom rolled VIM 7.1; compiled with Cygwin GCC

This article is perfect for setting up XDebug my setup with the exception of having to hack a little bit of the debugger.py. Since my binary of XDebug is native to Windows any file string XDebug out puts is a Windows native path ( /C:/…. ) and not a UNIX/Cygwin path ( /cygdrive/c/… ). A simple file.replace( ‘/C:/’, ‘/cygdrive/c/’) in about three locations of the Python debugger file.

I wonder who I could poke to try and get this to be an official feature? Maybe set in php.ini xdebug.env “cygwin” ? Thoughts?

Finally, using F5 to run till a break point is hit does not want to work. I get the following message in the trace window:

response xmlns:xdebug=http://xdebug.org/dbgp/xdebug xmlns=urn:debugger_protocol_v1 command=stack_get transaction_id=7

error code=5 : Command not available (Is used for async commands. For instance if the engine is in state “run” than only “break” and “status” are available).

message

command is not available

Has the protocol of GDBp stack_get been changed since the release of of this article? Any idea how I can get this fixed? Is there a point where I have to set the filename back to the Windows native path?

PS: I can single set through the executing file just fine ( as well as context, and cursor context ).

July 30th, 2008 at 3:54 pm

PHP Says:

knowledge of Debugging information is very useful and necessary to save time and increase performance. And this article has helped me alot.Thanks.

July 31st, 2008 at 2:42 am

MegaS Says:

Thanks for article!

Right now using this techinque for debugging code

August 2nd, 2008 at 2:22 pm

Ma'moon Says:

Thank you very much for this great article, it was really very useful and i do appreciate your time and effort to show it up.

answering the previous comment, what you have to do exactly is:

(1) mkdir -p ~/.vim/plugin “check if you have a .vim DIR in your home directory, if yes then you may omit the -p option from your mkdir command ==> mkdir ~/.vim/plugin” and make sure that you set the correct permissions over the created directory.

(2) mv /path/to/debugger.py ~/.vim/plugin/

(3) mv /path/to/debugger.vim ~/.vim/plugin/

and there you go, the plugin should be activated by now.

August 4th, 2008 at 5:29 am

Derek Schrock Says:

Good news. I found out what my problem was with setting break points.

From my previous posts I’m using a Windows build of XDebug in a Cygwin rolled VIM. My problem was that set_srcview from debugger.py used a native Windows fileuri not a Cygwin/UNIX type of path. This wasn’t that big of a deal; all I had to edit the file string in set_strview ( file = file.replace( ‘/C:/’, ‘/cygdrive/c/’ ) ).

After that setting break points wouldn’t want to set because of the filename that pass was no to spec. At first the cygwin path was sent /cygdrv/c/….. A quick change in Breakpoint.add() to switch file back to a native Windows path I thought would fix the problem ( file = file.replace( ‘/cygdrive/c/’, ‘/C:/’ ) )

Finally, after reading the DBGp spec the file name passed to breakpoint_set needs to have file:// or dbgp:

Back to Breakpoint.add() ( file = file.replace( ‘/cygdrive/c/’, ‘file:///C:/’ )

That fixed it!

August 4th, 2008 at 5:44 pm

Philipp Keller Says:

A solution of this eval thing is to type:

,e (for entering eval mode)

print_r($this, true)

which returns a string which then is printed in vi

August 7th, 2008 at 10:53 am

Paul Says:

Thanks so much. This made me feel great as it helped me get to the next level with vim. It’s so exciting to know I can use vim vs. big heavy IDEs for my PHP development. Your writing is very clean and clear and precise. Thanks again.

September 9th, 2008 at 7:15 am

Add debug support to Vim with xdebug.dll « PHP Hints Says:

[...] Tags: debugging php, php, vim, xdebug, xdebug plugin for vim If you are a Vim user, the articles How to Debug PHP with Vim and XDebug on Linux and Debugging PHP on Windows with Xdebug and Vim describe how to add xdebug support to Vim using a [...]

September 11th, 2008 at 10:53 am

pasunclou | Vim et Xdebug pour débugger votre code PHP Says:

[...] How to Debug PHP with Vim and XDebug on Linux (dont ce mini howto est largement inspiré) Ubuntu Forums How to install Xdebug for PHP5 on Ubuntu 7.10 [...]

December 12th, 2008 at 12:17 pm

An Ingres Blog › links for 2008-12-18 Says:

[...] Box.net Technical Blog » Blog Archive » How to Debug PHP with Vim and XDebug on Linux I have been meaning to look at XDebug for some time. (tags: debug development debugging xdebug php vim remotely) [...]

December 18th, 2008 at 8:01 am

blogs.planetingres.org » links for 2008-12-18 Says:

[...] Box.net Technical Blog » Blog Archive » How to Debug PHP with Vim and XDebug on Linux I have been meaning to look at XDebug for some time. (tags: debug development debugging xdebug php vim remotely) [...]

December 18th, 2008 at 8:05 am

Manuel Blechschmidt Says:

I just want to thank you for this article.

I love the debugging feature on the server. This saves a lot of time.

/Manuel

December 19th, 2008 at 4:56 am

Depuracion PHP con Emacs, geben y Xdebug LIBERTAD DIGITAL Says:

[...] plugin (Tutorial) (Editor [...]

January 21st, 2009 at 1:28 am

Metal3d Says:

Very useful and strangely easy to use. The interface is clearer than the Eclipse (PDT) and I am honestly impressed by the speed at which I understood how this plugin works.

Great !

February 9th, 2009 at 3:59 am

Juha Says:

Thank you! Seems to work just fine, saves lot of time. Have to admit, that I thought that “this will never work, but let’s see what happens”





March 19th, 2009 at 2:02 pm

gdb + vim, vim + macro Says:

[...] Box.net Technical Blog » Blog Archive » How to Debug PHP with Vim and XDebug on Linux [...]

April 10th, 2009 at 2:52 pm

Vim: 35 ressources pour apprendre à l’utiliser Says:

[...] Box.net Technical Blog ” Blog Archive ” How to Debug PHP with Vim and XDebug on Linux Article sur comment débuguer du php avec vim comme dans un ide. Ca a l’air cool. A tester. [...]

May 5th, 2009 at 4:26 pm

Jared Says:

Just thought I’d mention, for centos 5/rhel 5 users out there:

If you’ve enabled the epel repository, you can install xdebug with ‘yum install php-pecl-xdebug’, insert the debugger.py and debugger.vim scripts (at vim.org, linked in the above article) into your .vim/plugins directory, and put the xdebug settings (xdebug.remote_port and so on) into /etc/php.d/xdebug.ini, and this will work out of the box.





May 8th, 2009 at 10:26 am

Владимир Осокин Says:

Благодарен. Появилась новая мысль, но она нуждается в глубокой реорганизации старой идеи, займусь завтра. И сразу поделюсь информацией с читателями блога!

July 7th, 2009 at 8:41 am

Jim Says:

Installed a new server, fedora 10, recently and xdebug/debugger. Have xdebug and debugger vim running on 3 other machines and using it for sometime, it is a great tool. When I try to test on the newest server, the debugger session is started and is receiving output from the web server. But the php-code portion of the debugger window is empty. Any suggestions where to start looking ?

Thanks for your time…..

July 15th, 2009 at 12:41 pm

nomuna Says:

Man this is awesome… Thanks a lot. I got it working with a single PHP file…

But soon will try it with a really big Zend project…

Will keep you posted…

August 18th, 2009 at 1:11 pm

Алексей Андреев Says:

Такое впечатление, будто это не Вы писали. А какой то дежурный блогер по поручению.

August 20th, 2009 at 9:01 pm

Matias Says:

Im getting this error when i make F5 in vim.

waiting for a new connection on port 9000 for 5 seconds…

Connection closed, stop debugging (, error(98, ‘Direccixc3xb3n ya estxc3xa1 en uso’),

)

Full message:

(, error(98, ‘Direccixc3xb3n ya estxc3xa1 en uso’), )

File “/home/matias/.vim/plugin/debugger.py”, line 1078, in debugger_run

debugger.run()

File “/home/matias/.vim/plugin/debugger.py”, line 928, in run

self.protocol.accept()

File “/home/matias/.vim/plugin/debugger.py”, line 555, in accept

serv.bind((”, self.port))

File “”, line 1, in bind

September 17th, 2009 at 11:29 pm

sqz Says:

Amazing!

Although it conflicts a bit with my shortcut keys…still this is vim a true powerup!





September 22nd, 2009 at 2:29 pm

1 comment:

Anonymous said...
This comment has been removed by a blog administrator.