PHP Crashes Caused By Extensions

This post is very old and likely contains information that is no longer accurate and links which no longer work. Proceed with caution.

Once again when faced with updating PHP on a few servers, I encountered my favorite of all PHP quirks: After rebuilding extensions, PHP crashes and/or takes Apache down with it. Here are the errors that tend to show up:

• exited on signal 11 (core dumped)
• exited on signal 6 (core dumped)
• seg fault or similar nasty error detected in the parent process

And my personal favorite:

• httpd in free(): error: junk pointer, too high to make sense

I have seen this on PHP4 and PHP5, and with Apache 1.3 and 2.x. I’m not sure if it’s a problem inherent to how the FreeBSD ports system builds and installs the modules or if it’s just a problem in general. I had read once upon a time that rebuilding extensions in a certain order would fix it, and it did. I never got around to figuring out why this worked. Turns out, rebuilding them doesn’t really matter, but the order of the extensions being loaded does. Rebuilding fixed it because when a php extension port is rebuilt, it gets placed at the end of extensions.ini. I solved the problem by editing /usr/local/etc/php/extensions.ini and placing the lines for mysql, imap, and sockets at the end and in that order:

...
extension=mysql.so
extension=imap.so
extension=sockets.so

I’m not sure if the conflict is only with those three, or with others as well, but that fixes it on my servers. I tried it on three different setups, and before the change they all crashed and after the change they’re all running OK.

Hopefully if anyone else runs across this, it will help. If I get more time, I’ll dig into it more later.

Update 11/25/06:

There has been some more discussion of this on the FreeBSD-Ports mailing list and the FreeBSD-STABLE mailing list. Apparently at least part of this is due to the PHP recode,MySQL, and IMAP extension ordering. These extensions rely on c-client libraries with different overloaded hash functions. So the “magic” order at the end of extensions.ini should be:

...
extension=recode.so
extension=mysql.so
extension=imap.so
extension=sockets.so

There is also talk of building some logic into the PHP extension ports to ensure the ordering of the extensions so as to avoid this bug. Best of luck to those working on it!

Update 8/25/07:

I wrote a very hackish shell script that gets the job done keeping the extensions in this order. It’s not pretty, but it works. It can be found here: Fix PHP Extension Order Script. Read the full post: PHP Crashes Caused by Extension Ordering: A Workaround.

Edit 11/21/07:

Lately pspell has also become picky about ordering. I recommend placing it at the end (or at least anywhere after spl.so)

...
extension=recode.so
extension=mysql.so
extension=imap.so
extension=sockets.so
extension=pspell.so