Nerdstock.org - PHP extensions

PHP extensions

Each time I used PHP from the commandline, it crashed with a Segmentation fault: 11 (geheugendump gemaakt). Searching the internet told me that (at least on FreeBSD machines) this could be caused by the order in which the extensions are loaded.
Unfortunately, I could not find any site that listed the correct order (which is also a bit due to the fact that I have installed 55 extensions; no normal person would do, let alone document, that…).

rob@server:~> php -r 'echo "bla\n";'
bla
Segmentation fault: 11 (core dumped)
rob@server:~>

But finally I have found the correct order: I can now use PHP from the commandline without getting a core dump. Which is why I wrote this page.

A page which pushed me quite a way in the right direction, is pingle.org by Jim Pingle; he wrote a script that changes the order of the extensions in /usr/local/etc/php/extensions.ini (I think that's /etc/php/extensions.ini in Linux), and this way he gets his installation going.
Unfortunately, I still got a core dump after running his script…

Searching a bit further brought me to Gamecreature's blog; in a reply to a reply to his post, he describes who he reads the faulty extension from the core dump. So I followed his example:

rob@server:~> gdb php ./php.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc64-marcel-freebsd"...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.3...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /lib/libm.so.4...done.
Loaded symbols for /lib/libm.so.4
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Loaded symbols for /usr/local/lib/libxml2.so.5
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/local/lib/php/20060613-debug/session.so...done.
Loaded symbols for /usr/local/lib/php/20060613-debug/session.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x000000004862506c in __do_global_dtors_aux () from /usr/local/lib/php/20060613-debug/session.so
#2 0x0000000048632eec in _fini () from /usr/local/lib/php/20060613-debug/session.so
#3 0x000000004055e7dc in elf_hash () from /libexec/ld-elf.so.1
#4 0x000000004055e7dc in elf_hash () from /libexec/ld-elf.so.1
Previous frame identical to this frame (corrupt stack?)
(gdb) quit

So the problem was in the session extension.

I then moved the session extension all the way to the end of extensions.ini, following Jim Pingle's example, and re-ran his script again to make sure the rest of the order was correct.
This didn't quite give the desired result:

rob@server:~> php -r 'echo "bla\n";'
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613-debug/wddx.so' - /usr/local/lib/php/20060613-debug/wddx.so: Undefined symbol "ps_globals" in Unknown on line 0                                                                                       
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613-debug/memcache.so' - /usr/local/lib/php/20060613-debug/memcache.so: Undefined symbol "php_session_create_id" in Unknown on line 0                                                                    
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613-debug/soap.so' - /usr/local/lib/php/20060613-debug/soap.so: Undefined symbol "ps_globals" in Unknown on line 0                                                                                       
bla
Segmentation fault: 11 (core dumped)

But at least these are clear error messages, so I moved wddx, memcache and soap below session, and re-ran Jim's script.
Alas: a next test gave another core dump, and examining the core dump told me it was session again.

Well, then it became very obvious: if session can't be at the end of the file, try placing it at the beginning. And that worked: I can now use PHP from the commandline without errors:

rob@server:~> php -r 'echo "bla\n";'
bla
rob@server:~>

To finish this, I place my /usr/local/etc/php/extensions.ini below. If this one doesn't work for you (make sure you remove the extensions you don't have installed), at least you now know how to work towards a solution.

extension=session.so
extension=fileinfo.so
extension=crack.so
extension=ssh2.so
extension=imagick.so
extension=ldap.so
extension=simplexml.so
extension=dba.so
extension=ctype.so
extension=apc.so
extension=ftp.so
extension=mbstring.so
extension=tokenizer.so
extension=filter.so
extension=pgsql.so
extension=gmp.so
extension=mcrypt.so
extension=tidy.so
extension=xmlwriter.so
extension=mhash.so
extension=gd.so
extension=ncurses.so
extension=readline.so
extension=gettext.so
extension=iconv.so
extension=dbase.so
extension=calendar.so
extension=exif.so
extension=zlib.so
extension=curl.so
extension=mailparse.so
extension=xmlrpc.so
extension=bz2.so
extension=sysvmsg.so
extension=pdf.so
extension=openssl.so
extension=ming.so
extension=dom.so
extension=hash.so
extension=xmlreader.so
extension=gnupg.so
extension=bcmath.so
extension=pcre.so
extension=xsl.so
extension=wddx.so
extension=memcache.so
extension=soap.so
extension=spl.so
extension=sqlite.so
extension=mysqli.so
extension=mysql.so
extension=imap.so
extension=sockets.so
extension=pspell.so
extension=xml.so

Responses are welcomed:
rob[at]nerdstock.org

http://creativecommons.org/licenses/by-nc-sa/3.0/nl/deed.en