Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:47869 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16836 invoked from network); 11 Apr 2010 15:42:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2010 15:42:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.216 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.218.216 mail-bw0-f216.google.com Received: from [209.85.218.216] ([209.85.218.216:42353] helo=mail-bw0-f216.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B2/F0-11452-1EDE1CB4 for ; Sun, 11 Apr 2010 11:42:26 -0400 Received: by bwz8 with SMTP id 8so2027392bwz.23 for ; Sun, 11 Apr 2010 08:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=QV25RpEYP/5tWl6eDCLdfrZbPPW7JJdbFX+B2YX6j/g=; b=H5ddBX4tbKPkWFg2Q4um7rx5hnWlo8SnQpIin8Ab4rh9dKpqRc0ovyNcgs/yFhsUeL KcfunbgCI3NL1WrWgqmCXuDbSosrMmdX2qPwXjnmYGICRCG5aB0cNXB9xo77LCgn7L4W WwTHHX2u87fmlzAiWXGPOoQVKWEkJj9CGyRrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Px3savtYbTC6hj72yeDDiCO3rpY2kaycjgm7jv/NzedZKhCo9+dXXK8ojZZY9xJOpF KFVyytKBxaN+mn5cOTrU8ld5Ti0/tBcSl8FyhJ63yX12iiNsqtWeYaFatcKeaTKHmFCh eVqQ9//82mJO2v/O8NpOW9gqjW2xd5o8YH/78= MIME-Version: 1.0 Received: by 10.204.120.10 with HTTP; Sun, 11 Apr 2010 08:42:22 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Apr 2010 17:42:22 +0200 Received: by 10.204.81.80 with SMTP id w16mr3333030bkk.84.1271000542432; Sun, 11 Apr 2010 08:42:22 -0700 (PDT) Message-ID: To: Frederik Banke Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=0016e6da7de1d74cfc0483f7df18 Subject: Re: [PHP-DEV] PHP hangning on futex wait From: tyra3l@gmail.com (Ferenc Kovacs) --0016e6da7de1d74cfc0483f7df18 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 11, 2010 at 3:43 PM, Frederik Banke wrote: > Hi > > I have a problem with my php, once in a while an apache process will hang. > In apache's /server-status it looks like: > *11-1*111941/3/588*W* 0.20213490179.30.2227.03 xxx.xxx.xxx.xxx > localhostGET xxx.php?xxx=xxxAs you can see from this line the process has > been working for 21349sec and the status is W (Sending Reply). I can se > from > top that the process uses 0% cpu. > > I have been unable to find out what causes some of the processes to behave > like this. When I try the same request as a process that stalls it finishes > with no problem. The problem is that the request uses alot of memory and it > is never released so when there is many stalled processes the server > crashes. The stalled processes only occours on a few specific requests of > large searches so the page generation time is large for the request (30sec+ > range). > > I have tried to setup another server with the same configuration to debug > but I'm unable to reproduce the problem. I suspect it to be related to some > kind of deadlock that only occours in special cases, because of the futex > wait mentioned below. > > With strace and gdb on the process i get: > > strace -p 11194 > futex(0x7f9fefee3a00, FUTEX_WAIT_PRIVATE, 2, NULL > > (gdb) where > #0 0x00007f9fefc6a6de in ?? () from /lib/libc.so.6 > #1 0x00007f9fefbf4025 in ?? () from /lib/libc.so.6 > #2 0x00007f9fefbf026b in free () from /lib/libc.so.6 > #3 0x00007f9fefb9fb6d in setlocale () from /lib/libc.so.6 > #4 0x00007f9fe95d8e61 in zm_deactivate_basic () from > /usr/lib/apache2/modules/libphp5.so > #5 0x00007f9fe969d4ac in module_registry_cleanup () from > /usr/lib/apache2/modules/libphp5.so > #6 0x00007f9fe96a698b in zend_hash_apply () from > /usr/lib/apache2/modules/libphp5.so > #7 0x00007f9fe969bdad in zend_deactivate_modules () from > /usr/lib/apache2/modules/libphp5.so > #8 0x00007f9fe9656085 in php_request_shutdown () from > /usr/lib/apache2/modules/libphp5.so > #9 0x00007f9fe9711123 in ?? () from /usr/lib/apache2/modules/libphp5.so > #10 0x00007f9ff09e72d3 in ap_run_handler () from /usr/sbin/apache2 > #11 0x00007f9ff09eaa6f in ap_invoke_handler () from /usr/sbin/apache2 > #12 0x00007f9ff09f8430 in ap_internal_redirect () from /usr/sbin/apache2 > #13 0x00007f9fe8c47bd5 in ?? () from > /usr/lib/apache2/modules/mod_rewrite.so > #14 0x00007f9ff09e72d3 in ap_run_handler () from /usr/sbin/apache2 > #15 0x00007f9ff09eaa6f in ap_invoke_handler () from /usr/sbin/apache2 > #16 0x00007f9ff09f860e in ap_process_request () from /usr/sbin/apache2 > #17 0x00007f9ff09f5448 in ?? () from /usr/sbin/apache2 > #18 0x00007f9ff09eeca3 in ap_run_process_connection () from > /usr/sbin/apache2 > #19 0x00007f9ff09fcf76 in ?? () from /usr/sbin/apache2 > #20 0x00007f9ff09fd2ea in ?? () from /usr/sbin/apache2 > #21 0x00007f9ff09fde1a in ap_mpm_run () from /usr/sbin/apache2 > #22 0x00007f9ff09d360d in main () from /usr/sbin/apache2 > > > > So it looks like php hangs waiting for some futex. I have tried to > find the zm_deactivate_basic function but i have only found a macro > "#define ZEND_MODULE_DEACTIVATE_N(module) zm_deactivate_##module" > > This seems to point to the module basic, but i can't find this module > anywhere so i suspect it to be some kind of internal/core "module". > > Any ideas on how to proceed to find a solution? > > /Frederik Banke > I can't help you, but in the past I did see apache processes got stuck for some ajax requests, and because it was a third party application and I didn't had the time to debug it properly, I ended up writing a simple process which killed the long-running apache workers which stucked with the W status. Tyrael --0016e6da7de1d74cfc0483f7df18--