Debugging Drupal 6 with XDebug, Ubuntu 10.4 and Eclipse PDT: step-by-step

Chris's picture
Comments (18)
Post a new comment
Chris
8 September, 2010 - 10:39

Coming from a .NET background, I love the Visual Studio debugger. I can stop code execution at any time and look at the values of any of the variables. There's none of this dumping huge arrays to the web page and examining the output. I've wanted to set up a debugger for Drupal with Eclipse for a long time now, and setup instructions vary wildly. Here's my take on it.

You will need:

  • Ubuntu 10.4: other versions might work, and other Linux distros might work too, but paths and such will differ.
  • Eclipse PDT: I was using Helios, having downloaded the all-in-one.

I am also assuming you are running Apache on your local development machine and you want to debug sites locally on this machine only.

Installing XDebug

There's already a package with a version of XDebug compiled especially for Ubuntu, but as pointed out by Heine, this does not allow you to see all the variables in the current scope, so we will need to download and compile this for ourselves. This isn't that scary, so there's no need to worry.

At the time of writing, the latest version of XDebug is 2.1.0, but do check the XDebug downloads page to see if there's a more recent version and grab that instead. First, let's download it and extract it. You'll need a terminal open for this:

  1. $ cd ~
  2. $ wget <a href="http://www.xdebug.org/files/xdebug-2.1.0.tgz
  3. ">http://www.xdebug.org/files/xdebug-2.1.0.tgz
  4. </a>$ tar zvvf xdebug-2.1.0.tgz

Now you'll have a directory containing the source code for the PHP extension, but we need to compile it, which is only a few more commands. If you don't have the phpize command available on your system, you will need to install the php5-dev package (on other flavours of Linux this will be different):

  1. $ cd xdebug-2.1.0
  2. $ phpize
  3. Configuring for:
  4. PHP Api Version:         20041225
  5. Zend Module Api No:      20060613
  6. Zend Extension Api No:   220060519
  7.  
  8. $ ./configure --enable-xdebug
  9.  
  10. -- a whole load of config checks will appear here --
  11.  
  12. $ make
  13.  
  14. -- a whole load of compiler output will appear here --

This will produce a file called xdebug.so in the modules directory, so now we'll just copy this to the appropriate path, which is usually /usr/lib/php5/20060613+lfs for PHP 5.2, and if you're on 5.3, it will have 2009 in it.

  1. $ sudo cp modules/xdebug.so /usr/lib/php5/20060613+lfs/
  2. $ sudo chmod 644 /usr/lib/php5/20060613+lfs/xdebug.so

Now, edit Apache's copy of your php.ini file, which is usually at /etc/php5/apache2/php.ini. Add this section at the bottom:

  1. [xdebug]
  2. xdebug.remote_enable=1
  3. xdebug.remote_host="localhost"
  4. xdebug.remote_port=9000
  5. xdebug.remote_handler="dbgp"
  6. zend_extension=xdebug.so

Save the file, then restart your Apache. Reloading is no good here, so only a full restart will do (which is sudo service apache2 restart in case you need it).

Configuring Eclipse

Fire up Eclipse and let's have some fun with it. Debugging is hugely confusing, but the theory is something like this: the xdebug extension fires up its own local server on your machine and watches Apache like a hawk as it executes PHP, remembering all sorts of things like what variables' values are at various times. We just need to tell Eclipse how to connect to xdebug's local server to retrieve all the juicy information.

I'm assuming you already have a project set up with your Drupal code in it. Some of us work on single-sites, and others on multi-site installs. If you're on a single-site, the entire Drupal directory is probably at the root of your project. If you're using multi-site like us, we have one project for each site, and the root of each project is the site's directory inside drupal/sites/.

It really doesn't matter whether you use either approach here. That is to say that, even if your project only contains the site's code, and no Drupal code whatsoever, you can still debug the Drupal code itself! It took me a while to get my head around that one, but it does work.

Make sure your project is open and ready to work with. Right-click and choose Debug As -> Debug configurations. You will need one debug configuration for each of your Eclipse projects.

In the left pane you will see a load of options. We need PHP Web Page, so double-click this to create a new entry underneath. Give it a name, which can be the same name as your project. Change the debugger to XDebug.

Configuring XDebug in Eclipse PDT

We will need to create a new PHP server. In fact, we need a new PHP server for each Eclipse project, so click New and give it the same name as your project. Enter the URL that is used to access the local development copy of your site.

It really doesn't matter what you put in the File - I just used the root of the project itself here, as long as there is something.

For now, leave Break at First Line checked, because we want it to break at the first line in order to make sure it's running properly. Uncheck Auto Generate for the URL. Enter the URL of your local development site. The first part is greyed out and it's just what you set up earlier under PHP Server but the second part is the path to the root of the site, which, in most cases, will be just /.

Click Apply at the bottom and then take a deep breath. Now, click close, and have a look on the main Eclipse toolbar for the bug icon, which has a little down arrow next to it. Click the bug icon itself to begin debugging.

Debugging

Still with me here? If you've never debugged before, Eclipse will probably prompt about switching to the debugging workspace. When we're debugging, we use a lot of informational panes and tabs we don't normally want to see, so it makes sense to have a separate workspace for this, and just switch back to our main PHP workspace when editing the code.

I didn't actually understand the whole workspace concept, but I just went along with Eclipse and it turned out to work very well, allowing the windows to be arranged in a totally different way just for debugging, so I'd recommend allowing Eclipse to remember your decision by checking the box, then allow Eclipse to switch to the debugging workspace for you.

If everything has worked for you, you will be presented with a copy of Drupal's index.php file, and the debugger will have stopped execution at the first line of proper code in there. This is when you know the debugger works, so you can jump for joy and go get a celebratory cup of coffee (or something stronger) in recognition of this monumental achievement. Click the stop button at the top to end debugging.

Finishing touches

It's really annoying to break at the first line every time we debug, so return to your debug configuration by right-clicking the project and choosing Debug As -> Debug configurations, then unchecking Break at First Line.

Now, you can put breakpoints wherever you like, and once you click that debug button on the toolbar, execution will be halted at each breakpoint so that you can examine exactly what's happening in your code and what the variables say. You can even change the values of the variables, then let the script continue! Have fun...

Troubleshooting

As an anonymous user points out in a comment, sometimes you might see 'waiting for xdebug session' in Eclipse. The vast majority of the time, this is caused when the PHP extension has failed to load. If this is the case, there will be no XDebug session for Eclipse to connect to, and therefore you will never get past this step.

Fortunately it's easy to find out if PHP has XDebug loaded. Just create a PHP file that has the phpinfo() function in it (nothing else is needed except the obligatory php block around it), then visit that page in your browser. Amongst the plethora of configuration information, there ought to be an XDebug section. If there is not, you know that XDebug failed to load, and you ought to look in your Apache logs to find out why not!

18

Comments

Heine's picture
Heine8 September, 2010 - 14:54

The XDebug version in the repository for Ubuntu 10.4 shows all variables in the function scope as (or something similar). At least, it recently did so under Galileo - I had no luck working with Helios.

To fix, it's easiest to compile and deploy xdebug yourself. It's pretty easy to do.

Saffron X's picture
Saffron X29 August, 2012 - 04:03

I could not resist commenting. Exceptionally well written!

Heine's picture
Heine8 September, 2010 - 15:16

That should have been "... shows all variables in the function scope as <not defined>".

Chris's picture
Chris8 September, 2010 - 15:54
Thanks, Heine! I have updated the article to recommend compiling from source, which wasn't really that difficult, I have to say.
jonathan's picture
jonathan18 September, 2010 - 14:26

Compiling Xdebug from source can put you through a few hoops depending on your system configuration.

The gory detail can be followed here http://www.mugginsoft.com/content/building-installing-xdebug-xampp-os-x-106

Drupal Themes Showcase's picture
Drupal Themes S...8 September, 2010 - 16:40

Great article, thanks a lot !

Gerald's picture
Gerald12 September, 2010 - 11:49

Thanks a lot for this detailed article, that's a keeper.

A question: how is Helios working out for you? I keep getting the error "An internal error occurred during: "Semantic Highlighting Job" (it has been documented here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=315337 ). I've switched back to Galileo for now (OS: Windows XP).

Heine's picture
Heine30 September, 2010 - 13:32

I'm currently using Helios again, and was able to successfully open even Drupal 7's common.inc.

The workaround: Via preferences, "PHP > Editor > Syntax coloring" I unchecked "Enable" for each Syntax Element. That got rid of the errors, but left me with the default syntax coloring.

I've since enabled syntax coloring for a few elements (constants, parameter variables, super globals, task tags and variables). I'll experiment with enabling some others later, but so far, so good.

Overall Helios is a bit snappier than Galileo.

Chris's picture
Chris13 September, 2010 - 08:32
We're on Linux but I've seen that error you're talking about. The error pops up occasionally and doesn't seem to break anything, so I usually just get rid of it and continue. As always, Helios is slow, bloated and not particularly pretty, but it is the best PHP IDE we know about, so it's the one we continue to use.
Anonymous's picture
Anonymous16 September, 2010 - 15:05

An explanation of how to make a project in Eclipse is here:
http://drupal.org/node/157609

Anonymous's picture
Anonymous16 September, 2010 - 16:10

When trying to debug the launcher got stuck at 57% with "waiting for xdebug session".

I solved this by providing the full path to the xdebug.so extension in the php.ini file.

Girish's picture
Girish5 October, 2011 - 11:43

And I solved it by setting all the php.ini settings shown here http://stackoverflow.com/questions/7542331/xdebug-not-working-with-pdt-w... (without any syntax errors). Before that I had only the one line: zend_extension="/usr/lib/php5/20090626+lfs/xdebug.so"

Anonymous's picture
Anonymous17 November, 2010 - 11:23

Thanks a lot it was pretty straight forward...

Bryan Ross's picture
Bryan Ross1 April, 2011 - 20:14

Thanks Chris. This was fantastic.

Anonymous's picture
Anonymous25 April, 2011 - 14:24

this tutorial is working with xdebug 2.1.1
ubuntu 10.10 (Mavric)
eclise 3.5

thank you for the great work :)

Abdel Bolanos Martinez's picture
Abdel Bolanos M...6 July, 2011 - 14:27

Thanks a lot!!! I really did it and works perfectly!!!!!
Just to add that will be cool to place more images about the process on this part "The first part is greyed out and it's just what you set up earlier under PHP Server but the second part is the path to the root of the site, which, in most cases, will be just /."
Some windows users won't get it
Thank you...

williamtremblay's picture
williamtremblay10 August, 2011 - 17:55

This tutorial is by far the best-written one I have seen (and I have seen *many* over the past week or so) and also the one that ultimately worked (but see below). Thanks for using clear language to describe something so tricky. This process is *way* harder than it should be, and you have made it a lot less so.

As an example of how hard it is, I give you this case study.
I followed you all the way up to "Still with me here?" but then got that sickening feeling when I launched the new debug configuration and the web page opened in Firefox but the debugger blew past all my breakpoints and terminated. I then tinkered for an hour or so, restarted apache endless times, tweaked files and failed to get anything working, gave up and switched to NetBeans... Then I configured xdebug to work with netbeans, but was getting a "failure to bind" type error. This gave me a clue that port 9000 the culprit, so I messed around with netstat -an and lsof for a while. I compiled the xdebug debugclient and ran that for a while... still no joy in NetBeans.
In despair, I closed netbeans and consigned myself to use Eclipse with no debugger -- I had work to do, and it was alreasy 2:30 AM. But I could not resist trying *one more time* to debug in Eclipse. Somehow, it worked this time. Joy!
Near as I can figure, something about the process of compiling and running the xdebug client "woke up" xdebug in Eclipse. Silly, I know, but I can't explain it any other way, as I had not touched Eclipse for several hours.
Anyway, Thanks!

Hans Smit's picture
Hans Smit9 November, 2012 - 09:09

Concise is nice. Very well written. Your instructions got me up and running within 10-15 min. A previous attempt with another tutorial stumped me, and I gave up after banging my head for nearly 2 hours.
Many thanks!

Add new comment