First, compile using --enable-apc-mmap

Second, please provide a backtrace of one of these crashes and if possible a reproducing script.

Ok I recompiled APC with --enable-apc-mmap (Unfortunately I can't enable full debug for PHP) I did attach GDB to a PHP fast-cgi process and this is what I recieve when PHP segfaults.

(gdb) [Fri Mar 17 13:59:10 2006] [apc-error] apc_sma_free: could not locate address 0x892c3bc
bt
#0  0x40509b47 in wait () from /lib/libpthread.so.0
#1  0x0835de71 in main ()

same problem for me with 
gentoo 2.6.13-hardened-r2 kernel, 
apache-2.0.55-r2
php-5.1.2-r1
pecl-apc-3.0.10 compiled with "mmap"

Hi,

I've got the same problem on my cluster of PHP4 fast-cgi enabled servers. PHP segfaults, and then i get HTTP errors 500 when trying to access a script. After many debugging, I remarked PHP4 (5 does the same) segfaulted only on x86_64 Intel servers (bug occurs only on dual xeon EM64T, but not on AMD Opteron x86_64 platform, and not on my Intel Pentium 4 x86 platform too). The kernel message is like this :

php4[16116]: segfault at 00000000ff711a4c rip 0000000000864f90 rsp 00000000ff711a50 error 6

When running the debug enabled PHP, my logs were flooded by theses errors : 
/data/sys/root/sources/php-4.4.2/ext/apc/apc_compile.c(1830) :  Freeing 0x0857C464 (84 bytes), script=/home/xxx/www/inclusion/afficher_sondage.php
/data/sys/root/sources/php-4.4.2/ext/apc/apc_zend.c(34) :  Freeing 0x0857C404 (46 bytes), script=/home/xxx/www/inclusion/afficher_sondage.php
/data/sys/root/sources/php-4.4.2/ext/apc/apc_compile.c(1852) :  Freeing 0x085BD604 (128 bytes), script=/home/xxx/www/inclusion/afficher_sondage.php

My APC config :
APC Support 	enabled
Version 	3.0.10
MMAP Support 	Disabled
Revision 	$Revision: 3.84 $
Build Date 	Jun 25 2006 20:28:07

Directive	Local Value	Master Value
apc.cache_by_default	On	On
apc.enable_cli	Off	Off
apc.enabled	On	On
apc.file_update_protection	2	2
apc.filters	no value	no value
apc.gc_ttl	5	5
apc.max_file_size	1M	1M
apc.num_files_hint	1000	1000
apc.optimization	Off	Off
apc.shm_segments	1	1
apc.shm_size	1	1
apc.slam_defense	Off	Off
apc.stat	On	On
apc.ttl	5	5
apc.user_entries_hint	0	0
apc.user_ttl	0	0

Unfortunately, I haven't found a script which always reproduces the segfault, but in my logs the debug lines contained nearly all my PHP scripts, so I think this is related to FastCGI and its particular behaviour (executing scripts without restarting PHP between 2 scripts)

Note: disabling APC solves the problem, but it's obviously not the kind of solution I'm looking for :)

My software versions :
Linux kernel 2.6.17.1, PHP 4.4.2 and PHP 5.1.4, APC 3.0.10, GCC 3.4.2, all except GCC compiled from sources.

My server is running FreeBSD-6.1, with php-5.1.5/APC 3.0.11.
APC always cause my php-fcgi crash.

> pid 60195 (php), uid 65534: exited on signal 10.
Then my web server return 500 error.

Disabling APC, all is work fine. I can't enable debug for my php, and I havn't found the core dump, it's strange.

This issue is already last for a long time, from APC 3.0.?

The libpthread comments indicate that this php build was in all probability a ZTS build ?

A ZTS SEGV was just fixed in CVS, would you mind testing it out after that fix ?

I'm also getting segfaults with php-fcgi (PHP_5_1) and APC 
(HEAD). I've also tried with PHP_5_2, same issue.

Attaching gdb to a php-fcgi child results in:
=========
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1219229472 (LWP 9331)]
0x08286edb in _efree (ptr=0x8651158) 
at /usr/local/src/php_cvs/PHP_5_1-debug/Zend/zend_alloc.c:317
317             REMOVE_POINTER_FROM_LIST(p);
=========

The "-debug" in the source is misleading.. the error only 
happens when I compile PHP _without_ "--enable-debug". 
Configuring it with "--enable-debug" does not lead to the 
crashes.

I can reproduce theq crashes with the shipped apc.php 
file.. some page load fine, then some parts are broken. 
Either "Internal server" error or some "200 OK" in the 
middle.

This makes APC quite useless for fastcgi.. :/

I have the same problems with APC + PHP 5.2.1 + Apache2 not 
using FastCGI. One Apache thread will seg fault, and then 
every other thread to access that same script (possibly tens 
of thousands) will segfault behind it. 

Coredumps show stacks from all over:
#0  0x00002b8374e02660 in zend_binary_strcmp () from /usr/
lib64/apache2/modules/libphp5.so
#1  0x00002b8374e02a0d in zendi_smart_strcmp () from /usr/
lib64/apache2/modules/libphp5.so

#0  0x00002ae265ff7f0c in _zend_mm_alloc_int () from /usr/
lib64/apache2/modules/libphp5.so

And several in _efree

When running PHP+Apache in debug mode, I received the same 
messages as gabriel at oxeva dot fr, though I don't know if 
they're related to the problem at hand.


Also, I can't find any one script that reproduces the error. 
I can have normal operations for days at a time, but once 
one thread seg faults, everything behind it does too:
[Sun Feb 25 00:26:10 2007] [notice] child pid 31504 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:10 2007] [notice] child pid 31882 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:10 2007] [notice] child pid 32375 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:12 2007] [notice] child pid 31381 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:12 2007] [notice] child pid 31406 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:12 2007] [notice] child pid 31434 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:12 2007] [notice] child pid 31442 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:12 2007] [notice] child pid 31460 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core
[Sun Feb 25 00:26:13 2007] [notice] child pid 31355 exit 
signal Segmentation fault (11), possible coredump in /tmp/
core

I'm running Gentoo Linux 2.6.20 with all libraries and 
packages more up to date than the average box.

(update from last comment)

I upgraded to APC 3.0.13 and I am still seeing the bug. 
Here's the last stack trace:
#0  0x00002ba8620be08d in _zend_mm_free_int () from /usr/
lib64/apache2/modules/libphp5.so
#1  0x00002ba8620cb455 in _zval_ptr_dtor () from /usr/lib64/
apache2/modules/libphp5.so
#2  0x00002ba8620e8be2 in zend_hash_destroy () from /usr/
lib64/apache2/modules/libphp5.so
#3  0x00002ba8620dba53 in _zval_dtor_func () from /usr/
lib64/apache2/modules/libphp5.so
#4  0x00002ba8620cb455 in _zval_ptr_dtor () from /usr/lib64/
apache2/modules/libphp5.so
#5  0x00002ba8620e8cb2 in zend_hash_clean () from /usr/
lib64/apache2/modules/libphp5.so
#6  0x00002ba8620ff62c in zend_do_fcall_common_helper_SPEC 
() from /usr/lib64/apache2/modules/libphp5.so
#7  0x00002ba8620feb11 in execute () from /usr/lib64/
apache2/modules/libphp5.so
#8  0x00002ba8620fee04 in zend_do_fcall_common_helper_SPEC 
() from /usr/lib64/apache2/modules/libphp5.so
#9  0x00002ba8620feb11 in execute () from /usr/lib64/
apache2/modules/libphp5.so
#10 0x00002ba8620dda44 in zend_execute_scripts () from /usr/
lib64/apache2/modules/libphp5.so
#11 0x00002ba862095a3d in php_execute_script () from /usr/
lib64/apache2/modules/libphp5.so

Hi there!

I might be experiencing the same problem with PHP5.2.1 and the latest stable release of APC:

<Cipri> no, only that webserver crashes according to the logs
 <Cipri> [Sat May 26 15:04:34 2007] [notice] child pid 30582 exit signal Segmentation fault (11)
 <Cipri> [Sat May 26 15:04:54 2007] [notice] child pid 30486 exit signal Segmentation fault (11)
 <Cipri> [Sat May 26 15:04:54 2007] [notice] child pid 30689 exit signal Segmentation fault (11)

I am expiriencing same problems with the ZendCore for Oracle and php in fast-cgi mode with the latest APC at the time of the comment. Is there anybody working on this bug?

I am getting a very similar problem with FastCGI running on Windows with IIS and the recently released "production ready" FastCGI plugin from Microsoft.

Randomly, my FastCGI process dies and I get a FastCGI error in the browser as follows:

   FastCGI Error
   The FastCGI Handler was unable to process the request.

   Error Details:

       * The FastCGI process exited unexpectedly
       * Error Number: -2147467259 (0x80004005).
       * Error Description: Unspecified error

   HTTP Error 500 - Server Error.
   Internet Information Services (IIS)

This is with FastCGI configured to use protocol=NamedPipe.

When I switch to protocol=Tcp I get an error a lot less often but I still occassionally see the following:

   FastCGI Error
   The FastCGI Handler was unable to process the request.

   Error Details:

       * Error Number: 64 (0x80070040).
       * Error Description: The specified network name is no longer available.

   HTTP Error 500 - Server Error.
   Internet Information Services (IIS)

After this error I also get an error in the Event Log as follows:

Faulting application php-cgi.exe, version 5.2.4.4, faulting module php_apc.dll, version 5.2.4.4, fault address 0x00003746.

When I disable APC the errors go away indicating that it is an APC issue.

Configuration is IIS 6.0 running on Windows Server 2003 SP2 with PHP 5.2.4 (Non-thread-safe version) although I also experience the same problem with PHP 5.2.1 standard (thread-safe) version.

Please try the latest SVN from trunk (APC 3.1 branch)

Same here on Debian Lenny i386, ZendServer 4.0.6, PHP 5.2.11 fastcgi, ZendFramework 1.9.6, latest APC from trunk... setting apc.slam_defense=off seems to reduce occurence of segfaults but no working solution at all :(

> [Sun Feb 25 00:26:10 2007] [notice] child pid 31504 exit 
> signal Segmentation fault (11), possible coredump in /tmp/
> core

That looks exactly like my current try with APC. My System:
- FreeBSD 8.0
- apache-2.2.13
- php5-5.2.11
- mod_fcgid-2.3.4
- pecl-APC-3.0.19

A simple setup with only a phpinfo() script. With every second request to the phpinfo.php, the php-cgi core dumps.

1st request:
[Wed Dec 09 14:55:01 2009] [notice] mod_fcgid: call /usr/local/www/apache22/data/phpinfo.php with wrapper /usr/local/www/apache22/fcgid/php-wrapper
[Wed Dec 09 14:55:01 2009] [info] mod_fcgid: server wiedmann-online.homeip.net:/usr/local/www/apache22/data/phpinfo.php(31353) started

2nd request (F5 in browser):
[Wed Dec 09 14:55:24 2009] [warn] [client 192.168.255.22] mod_fcgid: error reading data, FastCGI server closed connection
[Wed Dec 09 14:55:24 2009] [error] [client 192.168.255.22] Premature end of script headers: phpinfo.php
[Wed Dec 09 14:55:28 2009] [notice] mod_fcgid: process /usr/local/www/apache22/data/phpinfo.php(31353) exit(communication error), get signal 11, possible coredump generated

Even interesting, eAccelerator is working in the same setup.

Regards,
Carsten

I can confirm this problem as well.

Debian lenny with:
- apache 2.2.9-10+lenny6
- php 5.2.11.dfsg.1-1 (running via fcigd)
- apc 3.0.19-2

After enabling APC first visit to site is fine. F5 to reload and error 500 is generated and following line appears in error_log:

[Tue Dec 29 15:45:21 2009] [notice] mod_fcgid: process /var/www/u00001/vhosts/test/www/info.php(6273) exit(communication error), get unexpected signal 11

PHP 5.2.1 
Zend Engine v2.2.0
APC 3.0.19 (without mmap)
Ubuntu 
kernel 2.6.20-15 x86_64

Enabling apc makes all pids result in server error 500:

"[notice] child pid 23067 exit signal Segmentation fault (11)"

Im considering to use apc 3.0.8, since the first bug report started after version 3.0.8<.

I believe this issue is caused when APC attempts to cache a missing source file, typically in a 404 situation.  APC should check for an empty length filename prior to attempting to compile / cache it.

Setting cgi.fix_pathinfo=0 solves the problem for me.

Here is my backtrace:

(gdb) bt
#0  0xb76fb211 in fread () from /lib/i686/cmov/libc.so.6
#1  0x083e6067 in zend_stream_stdio_reader ()
#2  0x083e60ec in zend_stream_read ()
#3  0x083b043e in lex_scan ()
#4  0x083b6988 in zendlex ()
#5  0x083aaa2b in zendparse ()
#6  0x083b1a1b in compile_file ()
#7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/src/APC-3.1.3p1/apc_main.c:525
#8  0x083d1a4d in zend_execute_scripts ()
#9  0x083870ea in php_execute_script ()
#10 0x08443a88 in main ()

And here you can see the empty filename which APC is attempting to compile / cache:

(gdb) frame 7
#7  0xb75012a0 in my_compile_file (h=0xbfa72fd8, type=8) at /usr/local/src/APC-3.1.3p1/apc_main.c:525
525	        return old_compile_file(h, type TSRMLS_CC);
(gdb) info locals
key = {data = {file = {device = 3215387700, inode = 154996816}, user = {identifier = 0xbfa6ec34 "", identifier_len = 0}, fpfile = {fullpath = 0xbfa6ec34 "", 
      fullpath_len = 0}}, mtime = 30, type = 0 '\0', md5 = "\000\000\004", '\0' <repeats 12 times>}
cache_entry = <value optimized out>
op_array = (zend_op_array *) 0x0
t = 1263419930
ctxt = {pool = 0x0, copy = APC_NO_COPY, force_update = 0}
bailout = <value optimized out>

I had the same problem.
OS: Debian Lenny 5.0.2
Apache: 2.2.9
PHP: 5.2.6-1+lenny2 with Zend Optimizer v3.3.9
APC: 3.0.19

But after installing eAccelerator (compilation from sources, which required php5-dev, gcc, make, and many dev-libs, etc.), APC suddenly has worked fine.
I hope this will help anybody.

That last comment makes no sense.  Well, it does, but 
probably not for the reason the commenter thinks.  
eAccelerator and APC cannot both act on the same request.  
Only one will grab the compile hook, and the one that does 
will probably depend on the load order.  Having both 
installed makes absolutely no sense.

Yes, you're right. Disabling eAccelerator returned to segfault.
Sorry.

I'm getting the same thing.

PHP 5.3.2 with Suhosin-Patch (cli) (built: Apr 16 2010 05:00:24)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

I have the following extensions installed:
pecl-APC-3.0.19
pecl-memcached-1.0.1
php5-5.3.2
php5-ctype-5.3.2
php5-gd-5.3.2
php5-hash-5.3.2
php5-json-5.3.2
php5-mbstring-5.3.2
php5-mcrypt-5.3.2
php5-pgsql-5.3.2
php5-session-5.3.2
php5-sockets-5.3.2
php5-xml-5.3.2

Running php via FastCGI (using spawn-fcgi) on nginx.

php-cgi.core is appearing in my web root.


gdb /usr/local/bin/php-cgi php-cgi.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 "i386-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `php-cgi'.
Program terminated with signal 11, Segmentation fault.
--snip "no debugging symbols found" messages--
Reading symbols from /usr/local/lib/php/20090626/sockets.so...done.
Loaded symbols for /usr/local/lib/php/20090626/sockets.so
Reading symbols from /usr/local/lib/php/20090626/apc.so...done.
Loaded symbols for /usr/local/lib/php/20090626/apc.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x28d22184 in apc_op_ZEND_INCLUDE_OR_EVAL () from /usr/local/lib/php/20090626/apc.so
[New Thread 287ca140 (LWP 100403)]
[New LWP 100450]
(gdb)

Step 1 of any bug report is to simplify your setup down to 
just core PHP stuff to make sure nothing you have added is 
causing your problem.  Like getting rid of eAccelerator and 
Suhosin or any other 3rd-party things.

Step 2 is to try the currrent svn code.

found out something strange:

phpinfo();
exit;
-> segfault

phpinfo();
session_write_close();
exit;
-> no segfault

maybe someone can test, if it has to do with session.

From my Linux experience, this bug is caused only by one thing:

Wrongly set SHM size in kernel and/or APC settings.

With standard apc.shm_size = 30, i get segfault (11) every time i try to spawn php-cgi processes.

But once i do the following:

echo "512000000" > /proc/sys/kernel/shmmax
set apc.shm_size = 64M

Then the problem completely disappears. PHP with APC becomes ROCK-solid, and NEVER segfaults running 24/7.

I forgot to add i was using PHP 5.3.x-6 with APC 3.1.7 for about a year, and since today I am using 5.3.6 also with 3.1.7, and still everything runs well.

I will report here if it starts segfaulting, but i highly doubt it.