Note: Problems described in this page were noted on FreeBSD 6.x. I believe most of them are solved in 7.x and newver versions of software in question.
Apache or PHP crash when PHP is upgraded
This is a known bug in PHP which is exposed by certain ordering of the extensions in extensions.ini. Some of the incompatibilities are documented on php.net, but most aren't. The bug usualy manifets on a newly upgraded PHP when the order of loaded extensions is semi- randomly changed (from a previously working configuration). See this thread for some info.
Apache parent process misteriously dies with PHP with lots of extensions
This one took a lot of time and karma to diagnose. The problem is: apache suddenly misteriously dies, or is in a weird braindead state where every new request cuases the child process assigned to serve it to die.
It seems that the reason for this is in the way FreeBSD handles threading libraries. In particular, FreeBSD has three threading libraries that can be used by any one process (libc_r, libthr, libpthread), in addition to using no threading libraries. As long as a single process uses only one of these options, all is well. The problem is that any single library can (erroneously!) bring a "forced" reference to a threading library, and Bad Things happen to a process that stumbles into such a situation.
My problem was that Apache was built with "prefork" mode (no threading), and one of the libraries used for PHP was bringing in libpthread. This conclusion was arrived to by a trial-and-error process with much educated guessing, since backtraces from the core dump didn't list the library, but it immediately rang a bell - wasn't there a shiny-looking switch in the process of building PostgreSQL's client libraries that said "build libpq threadsafe"? Yes it was. It turns out that libpq was not only being built threadsafe, it was also strongly linked to libpthread.so. This is bad, as it caused Apache to start without threading, then PHP (a DSO module in PHP) would load libpq.so, which would load libpthread.so for that Apache child, which would... somehow... propagate to the parent process and cause it to die trying to call _pthread_main_np function (for which there's only a "weak symbol" in libc and the threading libraries override it with their own implementation). Building libpq.so without "threadsafe" option fixed this.
Apache with PHP or PHP-CGI dies with SIGNAL 11 or SIGNAL 6
This error is commonly found after running recursive portupgrade on the php port. PHP has a long-standing issue with the order in which its extensions / libraries are loaded. On FreeBSD, this order is specified in /usr/local/etc/php/extensions.ini. Running portupgrade will reorder the extensions in an unpredictable way, breaking previously working installations. The solution is to find out which order of extensions works and make a backup of extensions.ini. Searching for "freebsd php extensions problem crash" on Google will find a lot of references to this problem, and the problem is often discussed in FreeBSD mailing lists. Apparently this is not a FreeBSD-specific problem, but it's commonly found here due to the way portupgrade works.
