oh, this was working just fine with PHP5.2.0RC4, and it doesn't show apc listed on a php -m because it is commented out of course.

i'll be willing to do anything to help debug/fix this. not sure why it's happening (?)

Is there some way to get a decent backtrace ? There was 
another fastcgi bug reported on APC, which disappears when 
php is built with --debug.

http://pecl.php.net/bugs/bug.php?id=7141

So even though it isn't really a new problem, it has 
survived mainly because I have no test setup which uses 
fastcgi.

I guess I'll put a fresh pot of coffee on and get to it ... :)

Just tested APC CVS HEAD with fcgi (with the following in apache2)

FastCgiServer /opt/php-fcgi/bin/php -processes 1
AddHandler php-fastcgi .php
<Location /cgi-bin/php>
    SetHandler fastcgi-script
</Location>
Action php-fastcgi /cgi-bin/php
AddType application/x-httpd-php .php

And it seems to work. 

Please note that every fast-cgi process has its own 
independent cache in this scenario, so I hope the apc mmap 
filemask is not set (or has the .XXXXX)

So I'll need a backtrace (i.e (gdb)bt full) on a core or 
something similar to help you.

I believe I need to compile PHP with debugging, and then get it to drop a core, correct? I can't reproduce this with lighttpd+fcgi, only Zeus+fcgi

You don't need to compile php with --debug, just CFLAGS="-g -O0" ./configure ... will do.'

And yes, you need to get it to dump a core.

This same problem exists in IIS with fastcgi and apc

There is no crash now. But, "Please note that every fast-cgi process has its own independent cache".

gopavl, how to fix this ?
Apache2, mod_fcgid (fastcgi) + lastest apc from head -> independent opcode cache for each fastcgi php instance. Why ? Is any way to fix this ?

Can verify this bug is also occurring on 5.2.10 using APC, once APC is disabled things run as expected. Specifically the database handler in my case is stored in a protected static property and being cleared before the session flushes.  I will post code as soon as I get permission.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

this also happens when php is loaded as a module in Apache 2.2:PHP 5.2.12 on Windows 2003.  here's the backtrace info, if you need I can e-mail to a developer.  This only happens when we attempt to enable php_apc.dll, however we need APC or XCache, I'd rather use APC however.

  Error In httpd__PID__25148__Date__09_23_2010__Time_10_31_09PM__443__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!shmdt+2c in C:\Program Files\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to write to memory location 0x00000018 on thread 0
 Please follow up with the vendor The PHP Group for C:\Program Files\PHP\php5ts.dll
 
  Error In httpd__PID__11048__Date__09_23_2010__Time_10_31_06PM__428__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!shmdt+2c in C:\Program Files\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to write to memory location 0x00000018 on thread 0
 Please follow up with the vendor The PHP Group for C:\Program Files\PHP\php5ts.dll
 
  Error In httpd__PID__25640__Date__09_23_2010__Time_10_25_15PM__631__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!guess_timezone+1c in C:\Program Files\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0c20084c on thread 0 

PHP5TS!GUESS_TIMEZONE+1CIn httpd__PID__25640__Date__09_23_2010__Time_10_25_15PM__631__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!guess_timezone+1c in C:\Program Files\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0c20084c on thread 0

Module Information 
Image Name: C:\Program Files\PHP\php5ts.dll   Symbol Type:  PDB 
Base address: 0x01800000   Time Stamp:  Wed Dec 16 11:01:36 2009  
Checksum: 0x00000000   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.2.12.12 
Managed DLL: False   Internal Name:  php5ts.dll 
VB DLL: False   Legal Copyright:  Copyright ? 1997-2007 The PHP Group 
Loaded Image Name:  php5ts.dll   Legal Trademarks:  PHP 
Mapped Image Name:  C:\Program Files\PHP\php5ts.dll   Original filename:  php5ts.dll 
Module name:  php5ts   Private Build:   
Single Threaded:  False   Product Name:  PHP Script Interpreter 
Module Size:  4.98 MBytes   Product Version:  5.2.12 
Symbol File Name:  C:\Program Files\PHP\dev\php-debug-pack-5.2.12-Win32-VC6-x86\php5ts.pdb   Special Build:  &

Seeing this issue on a fresh install using Nginx as well. Xcache for now I guess.

As I wrote a few weeks back at http://ubuntuforums.org/showthread.php?t=1761778 :

"It looks like php-apc was either causing the problem or allowing another bug to manifest. The immediate cause of the crash was a corrupt op_array bringing down the executor. Removing APC makes these op_arrays much shorter-lived; either the corruption was caused by APC, or without APC persisting them, they don't live long enough to manifest the crash."

One additional point is that it only seems to be going down in Serendipity's archives.  All the segfault messages point to those sorts of requests.  These are happening both with the Ubuntu package mentioned and from v3.1.9 via `pecl install apc`.  I'm going to see if I can reproduce this on another server, without real users.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.