Here's some additional info:

On a server where APC is currently working properly:

Breakpoint 3, apc_cache_find (cache=0xa20aa50, key=
      {data = {file = {device = 2051, inode = 3957296}, user = {identifier = 0x803 <Address 0x803 out of bounds>}}, mtime = 1131649062}, t=3957296)
    at /home/jdicioccio/APC-3.0.8/apc_cache.c:476
476             if (key_equals((*slot)->key.data.file, key.data.file)) {
(gdb) print *slot
$1 = (slot_t *) 0xb53f4880


On the broken server after the SIGSEGV was encountered:

(gdb) print slot
$1 = (slot_t **) 0xb53e69d4
(gdb) print *slot
$2 = (slot_t *) 0xffffffff

Changed version field to show APC version as well . . .

Are you running out of shared memory when this happens?

APC is happiest when it is running in a stable environment where it doesn't need to chop off the bottom of the cache to make room for new entries all the time.

I suggest these build flags:

./configure --enable-apc --enable-apc-mmap --with-apxs

And then crank up your apc.shm_size to 64 or 128.

If it isn't a cache-full thing, try to figure out which requests are causing this.  Is it always the same inode that shows up in the crashes?  If so, which script is this?

Something like: ls -lRi | grep 3548568
should find it for you.

You can then simply filter out this script from being cached for now and then work on creating the simplest possible version of this script that still crashes APC.  Once I have something I can use to reproduce the crash, I can fix it.

Thanks for the quick response.  Here's the file it's using:

(gdb) print (char *)*(0x85565cc)
$1 = 0x8556d5c "/var/web/htdocs/smarty/templates_c/%%7C^7CC^7CCF63B4%%radio_gd_next_show.txt.php"

This file contains:

<?php /* Smarty version 2.6.10, created on 2005-12-29 11:02:49
         compiled from radio_gd_next_show.txt */ ?>
6 days 8 hrs 58 mins

One interesting thing about the file is that the last line has no newline after it.  So when you cat the file, you don't see that last line.  I'm not sure if the lack of a newline would do anything to APC though.  I doubt it.  Depends on how you're reading in the file.

As for the stable environment.  I could try raising the limit, but even if that fixes our problem, isn't this still an issue?

Here are the options I passed to configure:

configured by ./configure, generated by GNU Autoconf 2.57,
  with options \"'--enable-apc' '--enable-apc-mmap' '--with-apxs' '--with-php-config=/usr/local/bin/php-config' '--with-apxs=/web/bin/apxs' 'CPPFLAGS=-I/web/include -DAPC_PHP4_STAT'

Sure, if it is a cache-full problem, it is still an issue, but it would be nice to know whether this is the case or not.  If it never happens again after increasing your cache size to 128M then this is a useful datapoint for me.

Does APC allocate shared memory in 1.4M chunks?  When I looked at ipcs -m before and after restarting apache with your 128m change, it showed something like the following:

0x00000000 294912     root      600        1474564    86         dest

I have confirmed that that segment belongs to apache.

Hello again . .  Since the issue with the crash seems to be *slot getting set to 0xffffffff, do you have any idea how it would get initialized like that?  Does the garbage collector do that?  Since you're likely a lot more familiar with the code than I, is there anywhere off the top of your head where you could see that pointer getting set to that value?

Nope, I don't see why something would be setting it to 0xffffffff

I guess you could put a gdb watch on it and see if you can figure out what does that if you can reproduce this reliably.

Is this still happening with current CVS?

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.