Andreas Gohr has posted an interesting article to his site showing you how you can easily visualize XDebug stack traces and make them a bit more clear than the usual output dump.

As alluded to in yesterday's post, I'm currently hunting an elusive bug with xdebug. The problem is, that it only happens sporadically and when I know it happened it is too late to set a break point. So usual debugging methods don't work. Instead I want to use xdebug's execution tracing: let it log all function calls and then pick through the log when the bug occurs.

[...] To ease my debugging I looked for tools that could read the computer readable format. I found a few promising candidates, but in the end they either didn't work or they did not provide what I needed. So instead of hunting the bug, I built a tool

His tool takes in the XDebug output and turns it into something much more readable and properly nested.

In this new post to his site Joshua Thjissen has shared some of his discoveries with Xdebug, Symfony 2 and problems with maximum nesting levels of objects in his testing.

Here you are, developing your code based on the Symfony2 framework. Creating a form here, add a Twig template there, until suddenly, boom! Your site doesn’t work anymore, and all the info you can find in your PHP logs is [an error about the maximum function nesting level being reached.

[...] What just happened? Did I create some kind of recursive function I wasn’t aware of, did somebody commit code that I accidentally pulled? Fortunately for us developers, there is a quick way to deal with this: google it...

According to the information he found via his search it's a common issue and can be "fixed" by bumping up the max_nesting_level to a higher value. He could have stopped there but he wanted to explain why this problem happened, what the nesting is all about, how it relates to the limitations of XDebug and why Twig could cause problems with it.

Continuing on with his look at using DTrace in with PHP, Chris Jones has a new post in the series showing how to add traces to Silex-based applications, including sample output.

In this blog post I show the full stack tracing of Brendan Gregg's php_syscolors.d script in the DTrace Toolkit. The Toolkit contains a dozen very useful PHP DTrace scripts and many more scripts for other languages and the OS. For this example, I'll trace the PHP micro framework Silex, which was the topic of the second of two talks by Dustin Whittle at a recent SF PHP Meetup. His slides are at Silex: From Micro to Full Stack.

He includes a brief guide to getting the DTrace support up and running based on instructions in a previous post based on some pre-build Oracle linux packages. He links to the latest DTrace Toolkit and the downloads page to get the latest version of Silex. He sets up a super-basic Silex application (one route, "hello") and shows how to run the DTrace against it. His sample output shows both the PHP files being called and the functions/methods called inside them resulting in an output over a thousand lines long.

One of the more difficult parts of development is debugging. Any tool that can help make your bug finding life simpler can be valuable. Raveren has submitted a new tool he's developed to make outputting your debugging information more useful - Kint.

It's basically a heavily improved var_dump and debug_backtrace version with some advanced behind the scenes action. The features description is in the google code page: http://code.google.com/p/kint/ but the interesting part is that this is the only dump tool, that can display the name of the dumped variable as well as use modifiers on the calling function.

The flow is traced back to its origin class/script and a token parser is used to find where the value was created. You can see a sample of how to use it over on its Google Code page. This also includes screenshots of the output and the configuration values you can set for things like a display path callback and the maximum number of levels to traverse through. You can download the current version here.

As David Soria Parra mentions in a recent post to his blog, the DTrace functionality has been backported to the PHP 5.3 branch and gives developers a bit more information about what's happening inside their applications.

For those not following the PHP development. We backported the DTraces probes from the abandoned PHP 6.0 branch, back to the new trunk PHP 5.3.99-dev. It is called 5.3.99 because the PHP dev community has not decided yet on a version number (5.4 or 6.0).

He gives the configure line to get it working on Solaris and Mac OSX and a sample line of code to ensure everything's working correctly. The results show the full execution of the example. This functionality can replace this extension from the PECL repository.

Chris Jones (of Oracle) has a new post to his OTN blog with a look at tracing in Oracle+PHP applications via some new methods added to the OCI8 extension.

No matter how it was installed, the PHP OCI8 extension provides a procedural API with familiar calls allowing efficient SQL and PL/SQL execution. The extension also supports some advanced Oracle features such as connection pooling. Recently some new OCI8 functions were checked into the PHP source code.

The new functions - oci_set_module_name, oci_set_action and oci_set_client_info - can be used on any existing (or new) Oracle connection to provide a bit more information about what's going on inside. You can get access to this information via the data dictionary views or through the SYS_CONTEXT() function in your SQL statements.

Derick Rethans has a new post today talking about using the Xdebug tool to track the memory usage in your application with some of its profiling capabilities, specifically function traces.

Function traces log every include, function call and method call to a file. If the xdebug.trace_format setting is set to "1" then the trace file is an easy-to-parse tab separated format. The information that is logged includes the time-index when the function started and ended, and it also contains the amount of memory that was in use when entering the function, as well as when leaving it.

He's written up a sample script (you can grab it from the Xdebug CVS server) that you can run on a file and push all ouf the output to the trace file for easy parsing. The script reads in the file and displays the results in a nice format on the command-line (easily adaptable for a web frontend).

Derick Rethans has made a quick post about an update he's made to the XDebug function traces to add in information on variable modifications.

After I had a quick look at the feasibility of this feature I spend some time on implementing it for Xdebug's HEAD branch that is going to become Xdebug 2.1. Variable modification tracing can be enabled by setting the php.ini xdebug.collect_assignments setting to 1. Of course this can also be done in either .htaccess or by using ini_set(). This setting requires general execution tracing to be enabled as well and it's only available for human readable trace files (the default format).

He gives examples of how two example scripts would be logged to the trace file - one inside of a basic function and another showing updates to the properties on a class.

Derick Rethans has made a quick post about an update he's made to the XDebug function traces to add in information on variable modifications.

After I had a quick look at the feasibility of this feature I spend some time on implementing it for Xdebug's HEAD branch that is going to become Xdebug 2.1. Variable modification tracing can be enabled by setting the php.ini xdebug.collect_assignments setting to 1. Of course this can also be done in either .htaccess or by using ini_set(). This setting requires general execution tracing to be enabled as well and it's only available for human readable trace files (the default format).

He gives examples of how two example scripts would be logged to the trace file - one inside of a basic function and another showing updates to the properties on a class.

On DevShed today the latest article in their XDebug series has been posted, a look at tracking the function call stack with help from functionality the extension provides.

Despite this inconvenience [pf not being able to get more in-depth], in this final part of the series, I’m going to show you how to work with a function of the library called "xdebug_get_function_stack()." This function can be used to keep track of the stack of function calls generated by a PHP script, in this manner completing this starting guide on this helpful extension.

After reviewing the script from the previous part (using xdebug_time_index) they get into this new function and what sort of output it provides. The stack is the trace of what functions and values were passed around in the script including information like the function name, parameters and the file it was in.