806 Software – Jason McClean

I’ve been working for a while on a command line PHP script that doesn’t use the webserver. The main problem I experienced was the inability of Eclipse/PDT to successfully launch a command line debugging session. This was because the PHP config that was loaded didn’t include most of the modules that I required (the first to error was MySQL).

Well, I needed to get work done so I soldiered on with “classic” debugging, adding a debug mode that controlled several aspects of the execution of the script, but mainly the output of liberally sprinkled debug statements to let me know what was going on when. We’ve all done it. Here print_r() and var_dump() are our friends. For a script that, on average, was taking 8 – 10 minutes to execute, this was a little time consuming to wait for the debug output if the issue was near the end of the execution, or waiting for the final result and inspecting that.

It is so much easier to check the code during execution. This has been invaluable when working on PHP driven websites, and there was no issue using Eclipse and Xdebug in that instance.

Well, the time eventually arrived when I realised I was spending far too much time in debugging and some of that time would be better spent sorting out the issue with Eclipse. As it turned out, it didn’t take that long to get to the bottom of the issue, thanks to messrs Google and StackOverflow.

The main problem with Eclipse/PDT launching a debug session for the command line was the configuration that was being loaded. On OSX, and many Linux based distributions, the PHP config is split amongst many separate files, usually split along module lines so each module has its own config file. Great stuff, great organisation. However, only the main configuration file (php.ini), was being copied to a temporary location and being loaded. This, of course, meant that many modules – including Xdebug – were not being loaded so not getting anywhere.

The reason for this was a decision taken by the PDT team to use the -n switch when loading the selected PHP interpreter. This stops additional config files being loaded and was a decision taken to stop some specific issues with multiple PHP installations and conflicting configuration files that could lead to segfaults.

The solution was to not have Eclipse launch the the script. Simple. The Xdebug configuration is already in place. It turns out that just a few environment variables need to be set for Eclipse prior to the script launch and a quick tweak to the Xdebug client in Eclipse to accept incoming connections.

This means that the script can be manually launched via shell and Xdebug will attempt to connect to the debug client IP address that is already set in the Xdebug module configuration. Eclipse immediately responds when a breakpoint it hit. Bingo. Full interactive debugging. Within seconds I had identified and fixed the current issue I was having and had spent a fruitless 20 or so minutes on quite late the night before.

The issue regarding the choice of the -n switch can be found here.

Configuring the debug client in Eclipse can be found here.

Setting up the script for debugging can be found here.

Thanks people. I should have looked into this so much sooner, but sometimes looming deadlines take your eye of the bigger picture.