php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57558 Segfault on exit in do_lookup_x()
Submitted: 2007-03-03 00:20 UTC Modified: 2009-03-10 19:45 UTC
From: tstarling at wikimedia dot org Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 3.0.13 OS: Fedora Core 3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: tstarling at wikimedia dot org
New email:
PHP Version: OS:

 

 [2007-03-03 00:20 UTC] tstarling at wikimedia dot org
Description:
------------
If you use Apache 1.3.x/PHP/APC on an x86_64 architecture, it will segfault on exit in the glibc function do_lookup_x(). This is probably a glibc bug. I have not yet isolated this bug sufficiently for the satisfaction of the glibc developers, but enough to produce a workaround.

The issue involves dynamic linking to libraries which depend on libraries with the DF_1_NODELETE flag set in their .dynamic section. The link map for the secondary library is corrupted when Apache shuts down PHP after reading its configuration, i.e. before it forks.

The workaround is to not link to any library with DF_1_NODELETE. This includes librt and libpthread. APC only uses librt when SHM is enabled. When using mmap, it is not required. 

Please change config.m4 to link to librt only when necessary.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-03-03 03:00 UTC] rasmus@php.net
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.
 [2007-03-03 12:03 UTC] tstarling at wikimedia dot org
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.
 [2007-03-23 06:45 UTC] cs at bitrockers dot de
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.
 [2007-03-23 10:16 UTC] tstarling at wikimedia dot org
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.
 [2007-05-26 15:32 UTC] janjaap at forest dot com
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)
 [2007-12-12 15:50 UTC] dimitrij dot hilt at fhe3 dot com
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
 [2008-06-30 04:16 UTC] dimitrij dot hilt at fhe3 dot com
Still exists in 3.0.19 too.

Dimi
 [2009-03-09 12:36 UTC] shire@php.net
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).
 [2009-03-10 19:45 UTC] shire@php.net
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
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 04:01:29 2024 UTC