But depending on the configured file mask, I do use shm calls.  See apc_mmap.c:

        /* 
         * If the filemask contains .shm we try to do a POSIX-compliant shared memory
         * backed mmap which should avoid synchs on some platforms.  At least on
         * FreeBSD this implies MAP_NOSYNC and on Linux it is equivalent of mmap'ing
         * a file in a mounted shmfs.  For this to work on Linux you need to make sure
         * you actually have shmfs mounted.  Also on Linux, make sure the file_mask you
         * pass in has a leading / and no other /'s.  eg.  /apc.shm.XXXXXX
         * On FreeBSD these are mapped onto the regular filesystem so you can put whatever
         * path you want here.
         */
        if(strstr(file_mask,".shm")) {
            mktemp(file_mask);
            fd = shm_open(file_mask, O_CREAT|O_RDWR, S_IRUSR|S_IWUSR);
            if(fd == -1) {
                apc_eprint("apc_mmap: shm_open on %s failed:", file_mask);
                return (void *)-1;
            }
            if (ftruncate(fd, size) < 0) {
                close(fd);
                shm_unlink(file_mask);
                apc_eprint("apc_mmap: ftruncate failed:");
                return (void *)-1;
            }
            shmaddr = (void *)mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
            shm_unlink(file_mask);
            close(fd);
        }

So I can't easily avoid librt here as far as I can tell.

Well, you could have a --disable-shm configure switch that disables that behaviour. No doubt other users sufferring this problem will be grateful. It's not going to matter to us at Wikimedia since we'll be patching out the SHM support regardless of what the official release does. I just thought I would be a good citizen and submit my findings upstream.

I'm not sure if our problem belongs to this bug, but I guess the described bug could also happen on apache2 enviroments?

So, we're running a Debian Etch distribution ( Linux sv3 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux),
Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8c,
and PHP 5.2.0. 

PHP was compiled with that configure line:
./configure --with-apxs2=/usr/bin/apxs2 --with-zlib --enable-sockets --enable-mbstring --with-gd 
--with-jpeg-dir=/usr/lib --enable-ftp --with-mysql=/usr/bin/mysql_config 
--with-mysqli=/usr/bin/mysql_config --with-curl


After upgrading from APC 3.0.12p2 to 3.0.13 (using PECL)
we're seeing a couple of segfaults each second in the apache error log:

e.g.
[Fri Mar 23 11:56:24 2007] [notice] child pid 19710 exit signal Segmentation fault (11)
[Fri Mar 23 11:56:24 2007] [notice] child pid 19711 exit signal Segmentation fault (11)
[Fri Mar 23 11:56:24 2007] [notice] child pid 19712 exit signal Segmentation fault (11)
[Fri Mar 23 11:56:25 2007] [notice] child pid 19714 exit signal Segmentation fault (11)
[Fri Mar 23 11:56:26 2007] [notice] child pid 19715 exit signal Segmentation fault (11)
[Fri Mar 23 11:56:26 2007] [notice] child pid 19719 exit signal Segmentation fault (11)
[Fri Mar 23 11:56:27 2007] [notice] child pid 19721 exit signal Segmentation fault (11)
[Fri Mar 23 11:56:28 2007] [notice] child pid 19724 exit signal Segmentation fault (11)


APC is running with default settings ( apc.shm_size = 512 ). After downgrading back to 3.0.12p2 everything works fine again.

If you need more information please give us advice how to supply that stuff.

No it's probably not the same bug, since our one affected 3.0.12p2 and lots of versions before that. This is not the first segfault bug in APC that Wikimedia has encountered, and I suppose it's not likely to be the last. 

The basic way to isolate segfaults is to run apache under gdb. First compile Apache, PHP and APC with debug symbols, by setting the environment variable CFLAGS=-ggdb3 when you configure each one. Start gdb and ignore SIGPIPE signals with

   handle SIGPIPE noprint nostop

Then run apache until it segfaults. At that point, some bugs will be identified by their backtrace. Run the command

   bt

and report its output in a new bug report.

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'v same problem on debian 4.0 (etch) x86_64 with apc-3.0.15 and apache1.3. Does not link with -lrt seems to help here.

Regards,

Dimi

Still exists in 3.0.19 too.

Dimi

This is a bug in glibc, and appears to be fixed in glibc-2.4.  You'll need to upgrade your glibc libraries (or remove the -lrt line from your APC makefile if you don't use shm_open).

Correction: this is actually fixed in glibc-2.5, (not 2.4)

Here's the corresponding bug report:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=6710