Last updated February 13, 2012. Created by pwolanin on May 20, 2008.
Edited by forestmonster. Log in to edit this page.

For advanced development a debugger may be very useful. A debugger will allow you to follow program execution and its effects, to observe the call stack of functions, and review the contents of variables at any point during execution.

Xdebug is the standard tool in PHP.

The main site:

http://xdebug.org/

Some articles on setting up and using it:

http://devzone.zend.com/article/2803-Introducing-xdebug

http://community.activestate.com/faq/how-do-i-get-php-debuggin

This Drupal module has additional tools for visualizing the Xdebug call traces:

http://drupal.org/project/visualize_backtrace

building xdebug.so

I downloaded the php package from php.net at http://www.php.net/downloads.php#v5 For Mac 10.4 and 10.5 I have Xcode installed, which includes gcc and other necessary comilation-related packages.

To build xdebug.so I went to the directory (assuming you unpack the PHP source code archive in your home dir):

~/php-5.2.5/bin/bin

and ran:

$ ./pecl install xdebug

this built xdebug.so and placed it in the direcrtory:
~/php-5.2.5/bin/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so

For the particular combination of MAMP + Komodo IDE

For my version of MAMP I copied xdebug.so to the following dir
(final dir name may vary by PHP version):

/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/

make sure Zend optimizer is OFF in MAMP preferences.

Make sure to restart apache after making these changes to php.ini. After verifying the location of xdebug.so, add the following to your php.ini file (or perhaps /etc/php5/conf.d/xdebug.ini, depending on your operating system):

zend_extension=/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000

OR

you can add this to .htaccess in your Drupal root or a parent dir:

php_value xdebug.remote_enable on

These (among others) may also be useful to add to .htaccess if you want to profile
memory usage:

php_value xdebug.auto_trace On
php_value xdebug.show_mem_delta On

To debug in Komodo, make sure Debug >> Listen for Debug Connections is enabled. In Drupal, add the query string: ?XDEBUG_SESSION_START=1 .

Alternatively, using the "easy Xdebug" extension for Firefox or the Xdebug helper for Chrome, you can initiate an Xdebug session with one click, instead of having to add the query string.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

You can follow these instructions (they apply to PDT):
http://www.eclipse.org/pdt/articles/debugger/os-php-eclipse-pdt-debug-pd...

Then use the compiled XDebug Shared Object binary which is available from ActiveState (works with PDT as well as Komodo):
http://aspn.activestate.com/ASPN/Downloads/Komodo/RemoteDebugging

--
Jakob Persson
NodeOne

--
Jakob Persson - blog

While debugging a Views 2 plugin, I found that Xdebug does not recognize breakpoints in files included by methods in objects. Since NetBeans supports only Xdebug, I was reluctantly forced to return to Eclipse PDT, which support the Zend debugger.

P.S. This page indicates that what Xdebug really has a problem with is files in different directories using the same name: http://www.rymland.org/en/blogs/boaz/5_mar_08/using-pdt-xdebug-for-debug...

Your conclusions seems wrong to me. If your IDE + xDebug is configured correctly, you'll stop at every breakpoint in your project (I'm referring to PDT only here. Not experienced with Netbeans).
See the section titled "Eclipse PDT" in the guide you've just linked. If you configure "Path mapping" correctly, those break points will be regarded. See the second screenshot in that section I just mentioned. Make sure to use file path in the "Path on server" section. Using "http://..." as the path passes PDT validation but will cause PDT/xDebug to ignore your breakpoints altogether (aside from "break first line", if you use that nagging feature :-)

Boaz.

--
Therapeutic PHP sessions

I think this tip about mapping the server path to the PROJECT path of eclipse (and not the local directory like I did before) is precious.
It should be one of the first things one should check out if his/her breakpoints don't seem to work.

Hamon Toda,
Dudy

I was able to install XDebug with Acquia Stack Installer on my OSX (localhost)

I downloaded XDebug (2.0.5) Source
http://xdebug.org/download.php

unpacked it on my desktop.

opend Terminal and moved into the directory

cd /Users/yournamehere/Desktop/xdebug-2.0.5/xdebug-2.0.5

I followed the guide, except the downloading part:
http://dlmax.org/2009/01/13/installing-xdebug-204-or-21-on-osx/

I run phpize (NOT phpsize) ;-)

phpize

run the following commands

export MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp"
export CCFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe"
export CXXFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe"
export LDFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load"
./configure --enable-xdebug
make

voila!

now copy the /Desktop/xdebug-2.0.5/xdebug-2.0.5/modules/ Directory to your acquia php bin folder:
/Applications/acquia-drupal/php/bin

Now I have 2 files
xdebug.so and
xdebug.la

in /Applications/acquia-drupal/php/bin/modules/

Edit your php.ini
I used the AcquiaDrupalControlPanel
settings -> config -> edit php.ini

Add the following line to your php.ini

[xdebug]
zend_extension=/Applications/acquia-drupal/php/bin/modules/xdebug.so

when you create a phpinfo(); page (http://www.php.net/phpinfo)

it should show something like

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans

and at the bottom xdebug variables

Now set up you programming enviroment with XDebug (another story.... working on it)

cheers
t

I installed xdebug and the debugger steps in and breaks at break points I place at function declarations in my .module files.
The problem is that if I try to "Step into" the functions, the debugger jumps to the next function call, and doesn't allow me to debug the code inside each function.
I guess this is not a limitation of the debugger, but something I configured\doing wrong.

Any suggestions?

If you set your breakpoints *on* the function declaration line, the debugger will break on the function declaration lines when an 'include' or 'require once' steps through and compiles them. Try setting your breakpoint on the first line of the function you wish to debug, or even on the line in whatever file is calling that function. The debugger should stop on that line when its actually executing it and not merely adding it.

In Eclipse PDT I set a breakpoint at the top of node-product.tpl.php file, but the debugger never seems to stop in it, and I can't figure out why?

I am using xDebug and I'm wondering if there might be some reason I can't think of.

Second, for debugging in Drupal what should I be using? xDebug or the Zend debugger? Does it make any difference at all in terms of debugging?

Thanks!

I ran into this problem. If you're caching and not rebuilding the theme registry on every page load, this could occur.