# PHP: Segmentation fault 11 after update



## Dare (May 25, 2013)

Hi,

I've been recently updating ports on my machine. After last update I cannot make PHP-fpm working. Simple 
`# php -v`
outputs me: 
	
	



```
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`

```
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:

```
(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.


----------



## ShelLuser (May 25, 2013)

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.


----------



## Dare (May 25, 2013)

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.


----------



## ShelLuser (May 25, 2013)

Dare said:
			
		

> Alright, I've managed to solve my issue partially. It was the php5-recode extension causing segfaults.


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.


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:


```
$ 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.


----------



## feld (Jun 27, 2013)

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


```
(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
```


----------



## feld (Jun 27, 2013)

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.


----------



## ootws (Oct 3, 2013)

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.


----------



## vijayrajah (Jul 25, 2014)

*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.



Thanks.... 

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

-Thanks
Vijay


----------

