PHP Crashes Caused By Extensions

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:


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:


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!

Edit 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: Read the full post here.

Edit 11/21/07: Lately pspell has also become picky about ordering. I recommend placing it at the end (or at least anywhere after


12 thoughts on “PHP Crashes Caused By Extensions

  1. I was struggling with this too (on FBSD 5.x) and tried every recommended ordering I found. The final fix for me was to recompile php5 and all the php5 modules with with less aggressive compiler optimization in /etc/make.conf. I normally have “CFLAGS=-O2 -pipe -funroll-loops -march=pentium4”. I reduced it to -O, recompiled all and restarted Apache, then the seg faults went away.

  2. Very helpful. I had segmentation fault problems with phpMyAdmin not opening after I made changes to php.ini and added extensions. Based on your advice, I looked at extensions.ini and found many duplicate lines. I removed all the duplicates and put mysql at the bottom and it fixed the problem. Thanks.

  3. thanks for this post, i’m going to try to reorder my extensions. any more info on this would be VERY appreciated.

  4. Pingback: Life on the edge of /dev/null » Blog Archive » PHP Extensions trouble

  5. Thanks a lot for your post, this was exactly what I was experiencing. ANY php script crashed with signal 6 at the end. First I thought it was the ‘simplexml’ extension causing this, because disabling it fixed the problem as well. But I needed this extension, and finally, moving ‘mysql’ to the end of the list worked. I don’t use the ‘imap’ or ‘socket’ extensions, though. (php-5.2.2 on FreeBSD-6.1-RELEASE)

  6. i had similar problem with 7.0-STABLE, except apache was not exiting (it was just hanging), but the cli version of php would core dump. fixed by putting imap at the end of the extensions (i did not have to move any others).

  7. I had similar problem with freebsd 7.1/amd64/apache 1.3.41/php 5.2.8/postgresql 8.3.x and

    this is mine /usr/local/etc/php/extensions.ini

    after httpd restart, apache go signal 11 and dumped core

    my solution:
    in httpd.conf add/uncoment line:

    ServerName yourhost.yourdomain.extension

  8. Ugh, still not having an effect for me.. My problem is narrowed down to, doesn’t matter where it is, or what’s going on it causes a bloody seg fault every time and I haven’t a clue why
    I run a strace on it and got this: sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0 , but I haven’t a clue what to do with that :(