About half the "Build failed" mails I've gotten from Jenkins in the last two weeks where not due to me breaking the tests but just PHPUnit segfaulting. "Wait! I know PHPUnit can't segfault!", only PHP itself can. And it does, quite often. For some reason that probably has to do with using PHP 5.2.OLD it doesn't survive generate the clover.xml file or the HTML report about 20% of the times it's being run.

He finds a solution to keep this from happening - not correcting the segfault as much as running the testing again to get it to pass. He wraps the call to PHPUnit inside of a simple shell script that tries to execute the PHPUnit testing suite as long as a segfault isn't thrown. If something was seriously broken, this could cause all sorts of problems, but in theory it's a simple hack that gets the job done.

Ran into a bug yesterday, where http://pecl.php.net/uuid in combination with http://pecl.php.net/imagick yielded a segfault when using uuid_create().

After trying to trace it down with a backtrace and cachegrind results, he (and Mikko & Pierre) found that both extensions were built against the libuuid.so.1 file. While that wasn't the issue directly, they did find a work-around that helped the issue - renaming some ini files so uuid was loaded first.

Once I discovered the segfault [from the FilterIterator code], I had to come up with a short code sample exposing the bug in order to report it.

He talks about the bug that led him to the segfault and a second bug that was a side effect of the first causing the first element to be skipped during iteration.

However, because we as PHP developers are lazy, provide a few GDB tricks to make this easier. First of all, it's only really going to work if you haven't stripped the symbols from your PHP and Apache binaries. Secondly, you still need to have the PHP source lying around somewhere.

He suggests using GDB to run the backtraces and create a file to help you track down the infinite recursion problem that could be giving you issues.

When executing code at the command line using php -r and PHP 5.2.5, be sure not to extend the Exception class. It will cause a segmentation fault.

He includes examples of the issue that would cause the problem and the bug he's filed in an effort to get it fixed.

Starting to get a little frustrated, I took a peek at my error logs (/var/log/httpd/error_log for the unitiated), and discovered a wonderful message [about the segfault]. As any person scratching their head would do, I hit up google.. to no real avail. Just a bunch of php bug reports. So, what happened, and how did I fix it?

After searching through the code and narrowing down where it could be, the culprit looked like a custom session handler he was using. It uses MySQL to store the sesion information and, unfortunately, when Ian had compiled the server he didn't let PHP know about his unique setup.

His default installation was trying to use the default MySQL information (including the socket) to reach the database. Obviously failing, the server simply gave up and segfaulted. Thankfully, all it takes it a recompile with a few extra parameters and you're back in business.

As per Derick:

Because of this I'd like to release a 4.4.6 soon with this fixes. As there is also an upgrade to pcre 7.0 we'd need at least one RC, which I plan to release on Thursday.

Users of the PHP 4.4.x series should keep watch for this new update to correct the issue quickly.

I've been playing about with using PDO to work with mysql. Something's not quite right in there, and it's resulting in a segfault when I run some local unit tests.

PDO objects themselves are created and destroyed when I'd expect them to be, as the objects go out of scope. The problem is that the PDOStatement objects aren't doing the same. According to gdb, PDOStatement objects are only getting cleaned up when php_request_shutdown() runs; never before.

Surely we should be seeing PDOStatement objects being destroyed before their corresponding PDO object?

He finds that there are relly two problems at work here - persistence of PDOStatement objects and PDO objects' destruction before their corresponding PDOStatement objects.

He asks for any opinions on the matter from anyone with the experience out there to help squash these bugs.

Included in this edition are mentions of:

• patches applied this week (GtkTreeModel::iter_nth_child, GtkTreeModel::iter_parent, GtkTreeModel::get, GtkWidget::is_visible)
• a fix for a segault dealing with the drag-n-drop functionality
• the release of a new Glade tutorial
• a question about creating your own widgets to extend PHP-GTK's current set
• a new package release by Christian on the Gnope.org site for a drag-n-drop development environment.

You can get the complete details on each of these stories from this edition of the latest from the world of PHP-GTK.