In a new post to his blog Ilia Alshanetsky takes a look at PHP's output buffering feature and some interesting things he found when testing some recent code (hint: it has to do with PHP's "interesting" management of the buffer).

While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual.

Through a bit more testing he found that, if a buffer provided for content isn't enough, PHP automatically bumps it up by 10kb each time - a waste of resources if you only need a small subset of that. He includes a small patch he made to the PHP core API that allows for defining a custom buffer size and, if it's not enough, bumps up the buffer size by 1kb instead of 10kb.

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.

As a part of one of her projects, Lorna Mitchell had a need to deploy database patches as a part of her overall deployment process. Obviously, doing this manually every time can be a hassle so she came up with a script that does the work for her (based on a patch_history table).

My current project (BiteStats, a simple report of your google analytics data) uses a basic system where there are numbered patches, and a patch_history table with a row for every patch that was run, showing the version number and a timestamp. When I deploy the code to production, I have a script that runs automatically to apply the patches.

The script uses the number-based patch names (such as patch1.sql) and finds the latest ones that haven't been applied based on the highest values for the patch_number column in the database. This number is updated by the patches themselves when they're run to avoid any confusion in the script itself. She has it running as a part of her phing build process as a part of a Zend Framework application.

On the main PHP site there's a new announcement about a critical update in a new version to both the PHP 5.2.x and 5.3.x series of releases to correct a problem that could cause a hang or crash from user input - 5.3.5 and 5.2.17.

The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17. This release resolves a critical issue, reported as PHP bug #53632 and CVE-2010-4645, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.

All users are strongly encouraged to update their releases. While the problem only happens in certain circumstances, it can still be a huge problem since the data comes directly from the user. For more information about the issue see this post.

Giorgio Sironi has a new post to his blog about a "refactoring" he's done of PHPUnit's mock objects to make their creation with getMock easier.

Not an actual refactoring, but at least the introduction of a layer of indirection, a Parameter object, called PHPUnit_Framework_MockSpecification. I have already written the patch in a branch of my github repository. They are actually two independent patches, since PHPUnit core and the mocking component are in two separate repositories.

If you create a basic object, the creation is simple, but when you start wanting to use one of the other optional parameters down the line, things can get messy. His solution adds methods like disableOriginalConstructor and disableAutoload to make this simpler. You can find the patches on his github account.

UPDATE: This feature has been included in the latest PHPUnit master branch.

For those that have considered contribute back to the WordPress project but weren't sure what the experience might be like, you should check out this helpful post from Aaron Jorbin with his story.