The PHP Roundtable podcast, hosted by PHP community memeber Sammy K Powers, has posted its latest episode: Episode #68 - PHP's Dirty Little Segfault Secret. This time Sammy is joined by guest and core PHP developer Sara Golemon

PHP is known for running really bad code really well. But it has a dirty little secret: deep within its code is a hidden "stack bomb". You can cause PHP to completely crash with just a few lines of code. Today we discuss why this happens and what we can do to fix the issue.

You can listen to this latest episode either through the in-page audio or video player, over on YouTube or by downloading the audio directly. If you enjoy the show be sure to subscribe to their feed and follow them on Twitter for updates on when new shows are released.

Volker Dusch has a new post to his blog looking at handling segfaults during code coverage generation that might come up during your continuous integration process (with PHPUnit flavor unit tests).

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.

If you've been using (or will be using) the uuid and imagick extensions for PHP, you might be able to save yourself a lot of headache by reading this new post from Lars Strojny about his segfault woes.

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.

In this quick post to his blog Matthew Turland shares a "kink" he found in using the FilterIteractor SPL iterator when working with the Phergie project's code.

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.

Derick Rethans has shared a quick tip for locating a code crashing kind of problem with your application when something like XDebug isn't around.

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.

In a new post to his blog, Paul Jones anout a small issue when working with the PHP 5.2.5 command line functionality - a segfault if you extend the Exception class.

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.

In recent work, Ian Selby came across something odd - a setup where PHP was segfaulting without any real indication of where the error might be:

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.

In recent work, Ian Selby came across something odd - a setup where PHP was segfaulting without any real indication of where the error might be:

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.

According to this new post on DynamicWebPges.de and a message from Derick Rethans on the php.internals mailing list, there's an issue with PHP 4.4.5 where sessions are causing segfaults when register_globals is set to "On".

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.

According to this new post on DynamicWebPges.de and a message from Derick Rethans on the php.internals mailing list, there's an issue with PHP 4.4.5 where sessions are causing segfaults when register_globals is set to "On".

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.