PHP: Segmentation fault 11 after update

Dare

Dare

Hi,

I've been recently updating ports on my machine. After last update I cannot make PHP-fpm working. Simple
# php -v
outputs me:
Code: 
Segmentation fault: 11 (core dumped)
So I've tried to use gdb but it give me no clues:
# gdb /usr/local/bin/php php.core
Code: 
Loaded symbols for /usr/local/lib/php/20100525-debug/xmlwriter.so
Reading symbols from /usr/local/lib/php/20100525-debug/zlib.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/zlib.so
Reading symbols from /usr/local/lib/php/20100525-debug/session.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/session.so
Reading symbols from /usr/local/lib/php/20100525-debug/tokenizer.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/tokenizer.so
Reading symbols from /usr/local/lib/php/20100525-debug/hash.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/hash.so
Reading symbols from /usr/local/lib/php/20100525-debug/soap.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/soap.so
Reading symbols from /usr/local/lib/php/20100525-debug/gmp.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/gmp.so
Reading symbols from /usr/local/lib/libgmp.so.10...done.
Loaded symbols for /usr/local/lib/libgmp.so.10
Reading symbols from /usr/local/lib/php/20100525-debug/ctype.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/ctype.so
Reading symbols from /usr/local/lib/php/20100525-debug/exif.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/exif.so
Reading symbols from /usr/local/lib/php/20100525-debug/mbstring.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/mbstring.so
Reading symbols from /usr/local/lib/libonig.so.1...done.
Loaded symbols for /usr/local/lib/libonig.so.1
Reading symbols from /usr/local/lib/php/20100525-debug/phar.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/phar.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x00000008056a3d02 in hash_lookup (hashtab=0x80e5311f0,
    key=0x7fffffffd280 "1dH\b\b") at misc.c:349
349     misc.c: No such file or directory.
        in misc.c
[New Thread 802407400 (LWP 106676/php)]

Ok, so let's look at backtrace:
Code: 
(gdb) bt
#0  0x00000008056a3d02 in hash_lookup (hashtab=0x80e5311f0,
    key=0x7fffffffd280 "1dH\b\b") at misc.c:349
#1  0x00000008084422a0 in find_alias () from /usr/local/lib/librecode.so.3
#2  0x00000008084436ab in recode_new_outer ()
   from /usr/local/lib/librecode.so.3
#3  0x00000008081b6ec8 in zm_startup_recode ()
   from /usr/local/lib/php/20100525-debug/recode.so
#4  0x000000000063e5e8 in zend_startup_module_ex (module=0x8025888c0)
    at /usr/ports/lang/php5/work/php-5.4.15/Zend/zend_API.c:1696
#5  0x0000000000648d0a in zend_hash_apply (ht=0xa5d360,
    apply_func=0x63e440 <zend_startup_module_ex>)
    at /usr/ports/lang/php5/work/php-5.4.15/Zend/zend_hash.c:716
#6  0x000000000063eadc in zend_startup_modules ()
    at /usr/ports/lang/php5/work/php-5.4.15/Zend/zend_API.c:1823
#7  0x00000000005aebe3 in php_module_startup (sf=0xa41c40,
    additional_modules=0x0, num_additional_modules=0)
    at /usr/ports/lang/php5/work/php-5.4.15/main/main.c:2210
#8  0x00000000006d6bdf in php_cli_startup (sapi_module=0xa41c40)
    at /usr/ports/lang/php5/work/php-5.4.15/sapi/cli/php_cli.c:414
#9  0x00000000006d8d93 in main (argc=2, argv=0x7fffffffd780)
    at /usr/ports/lang/php5/work/php-5.4.15/sapi/cli/php_cli.c:1344

And I'm stuck here. Please advice gentlemen.
 
Well, there isn't really much to go on here. You mention PHP-fpm but basically you're using one of the php5 ports where you enabled the FPM compile option. And because there's more to PHP than merely the base system my first question would be how you can be sure that this is related to FPM?

PHP usually has several extensions enabled, have you recently upgraded any of those and perhaps already tried to disable some of them?

Speaking of FPM; have you tried to rebuild PHP without FPM enabled to see if that would stop making it segfault?

The thing is; FPM or FastCGI Process Manager, is a pretty specific tool. You don't simply use it by starting PHP; it's main task is to "daemonize" the PHP process, which you don't do when checking the version of the PHP runtime environment. What you are doing is telling PHP to parse the php.ini file, load any optional extensions and then processing the given command.

So I can't help wonder if the problem could be somewhere else.
 
Alright, I've managed to solve my issue partially. It was the php5-recode extension causing segfaults. I've learned also that renaming extensions.ini to backup_extensions.ini doesn't do the trick because it seems that php is looking for any .ini file in /usr/local/etc/php and processes them. Turning off and on each extension lead out me to bricked recode. Currently I've turned it out temporarily.
 
Dare said:
Alright, I've managed to solve my issue partially. It was the php5-recode extension causing segfaults.
Click to expand...
Good work! I had a hunch it would be something like that, but only because it usually is ;)

Dare said:
I've learned also that renaming extensions.ini to backup_extensions.ini doesn't do the trick because it seems that php is looking for any .ini file in /usr/local/etc/php and processes them.
Click to expand...
Correct.

This is an option which gets set when compiling PHP. The easiest way to check for these options is using the php-config command:

Code: 
$ php-config | grep configure-options
  --configure-options [--with-layout=GNU --localstatedir=/var --with-config-file-scan-dir=/usr/local/etc/php --disable-all --enable-libxml --enable-mysqlnd --with-libxml-dir=/usr/local --with-pcre-regex=/usr/local --with-zlib-dir=/usr --program-prefix= --with-apxs2=/usr/local/sbin/apxs --with-regex=php --with-zend-vm=CALL --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.1]
See --with-config-file-scan-dir up there, with the value /usr/local/etc/php?

You can find the official explanation of this option here. It basically scans the directory for .ini files.

It might be possible to stop parsing by renaming the extension from ini into something else (for example .ini_old) but I'm not sure about that (this does work fine with Apache, but that's only because it specifically includes files with a .conf extension and nothing else).

Hope this can help too.
 
I've hit this as well. Looks like php53-recode might be broken?

Code: 
(gdb) bt  
#0  0x0000000806626d02 in hash_lookup (hashtab=0x8027e9740, key=0x7fffffffd260 "Q\211\032\f\b") at misc.c:349  
#1  0x000000080c1643c0 in find_alias () from /usr/local/lib/librecode.so.3  
#2  0x000000080c1657cc in recode_new_outer () from /usr/local/lib/librecode.so.3  
#3  0x000000080bed8ec8 in zm_startup_recode () from /usr/local/lib/php/20090626-debug/recode.so  
#4  0x000000000063632c in zend_startup_module_ex (module=0x8024b1340) at /wrkdirs/usr/ports/lang/php53/work/php-5.3.26/Zend/zend_API.c:1617  
#5  0x00000000006407ae in zend_hash_apply (ht=0xa49a80, apply_func=0x636170 <zend_startup_module_ex>) at /wrkdirs/usr/ports/lang/php53/work/php-5.3.26/Zend/zend_hash.c:877  
#6  0x00000000006364f7 in zend_startup_modules () at /wrkdirs/usr/ports/lang/php53/work/php-5.3.26/Zend/zend_API.c:1666  
#7  0x00000000005aa2d9 in php_module_startup (sf=0xa2ffa0, additional_modules=0x0, num_additional_modules=0) at /wrkdirs/usr/ports/lang/php53/work/php-5.3.26/main/main.c:2089  
#8  0x00000000007285ff in php_cli_startup (sapi_module=0xa2ffa0) at /wrkdirs/usr/ports/lang/php53/work/php-5.3.26/sapi/cli/php_cli.c:398  
#9  0x00000000007293bc in main (argc=2, argv=0x7fffffffdb60) at /wrkdirs/usr/ports/lang/php53/work/php-5.3.26/sapi/cli/php_cli.c:770
 
actually, appaers you're using php 5.4 and i'm using php 5.3...

curious...

Actually, it appears you're using PHP 5.4 and I'm using PHP 5.3. Curious.
 
For those who are having difficulty with recode.so for PHP 5.x, simply edit /usr/local/etc/php/extensions.ini and move recode.so up above imap.so and this will solve your problem. I've tested this with all modules and FPM enabled. I hope this helps you out.
 
Re:

ootws said:
For those who are having difficulty with recode.so for PHP 5.x, simply edit /usr/local/etc/php/extensions.ini and move recode.so up above imap.so and this will solve your problem. I've tested this with all modules and FPM enabled. I hope this helps you out.
Click to expand...

Thanks....

(I know this is an old thread.. This worked for me... (Do i need to open a BUG?))

-Thanks
Vijay
 
You must log in or register to reply here.
Back
Top