Using the Valgrind tool can give you a good window into the inner workings of your PHP script (at a very low level) but the results it gives can be a bit confusing to interpret. In his latest post Derick Rethans uses the memcheck tool that comes as a part of Valgrind to monitor memory usage and interprets some of the results.

Memcheck is really valuable for C and C++ developers and something you should learn, especially when you write PHP extensions. Memcheck's error messages can sometimes be difficult to understand, so with this (infrequent series), I hope to shed some light on it. Let's have a look at the following Valgrind error output, which I encountered while debugging issue PHP-963 of the MongoDB driver for PHP.

He walks though the output and how to spot the actual error - a reference to a null pointer in the C code. He tracks it back through the code and finds the spot where it references the wrong memory segment in the Mongo PHP extension code.

In short, an error where Address 0x38 is not stack'd, malloc'd or (recently) free'd has a low address in the message often means a NULL-pointer dereference.

In the process of some development he's been doing on various shared modules for PHP, Derick Rethans stumbled across an issue with using Valgrind to test his code:

While testing whether I correctly free all memory with Valgrind, I ran into the issue where I couldn't see the stack frames of where the memory leaks occurred in the extensions, and once I even ran into a Valgrind bug. The reason why Valgrind could not show the function names belonging to the stack frames is because PHP had already unloaded the shared extensions from memory.

A work-around he found was compiling the modules, but he wanted something "more correct" and less of a hassle. As a result he added a check for the ZEND_DONT_UNLOAD_MODULES environment flag to the PHP core to handles this case specifically. He includes a snippet of example code showing the Valgrind results with and without the flag.

Douglas Clifton has a quick new post to his blog looking at an invaluable tool in application development (and not just in PHP) - cachegrind output.

Valgrind is a entire suite of open-source tools, including basic debugging, profiling, and more advanced techniques such as threading, memory management, and leak detection. For the purposes of this article, I will focus on Cachegrind, and in particular within the domain of Web applications. Although there are a number of developers contributing to Valgrind, Julian Seward is the original designer and author.

He talks about the cachegrind software and the PHP-based profiler that can create these files - XDebug. He also includes a list of a few of the cachegrind viewers including KCachegrind and Webgrind.

Joakim passed along a note today about a new web-based frontend for XDebug:

My about page has mentioned a web based frontend for Xdebug for some time. The project has a name now: The idea for Webgrind, a spin on Valgrind, came from lack of profiling tools for PHP, particularly on OSX. Though it is possible to install kcachegrind on osx it seems overkill for many uses and is definitely not as easy as unzipping a folder to the webroot.

He and Jacob Oettinger have started up the project and have posted some initial code over on the Google Code page for Webgrind. You can check out a screenshot of it in action here too.