From owner-freebsd-questions@FreeBSD.ORG Fri Feb 22 16:44:08 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7492F16A405 for ; Fri, 22 Feb 2008 16:44:08 +0000 (UTC) (envelope-from fbsd.questions@rachie.is-a-geek.net) Received: from snoogles.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3F10613C43E for ; Fri, 22 Feb 2008 16:44:08 +0000 (UTC) (envelope-from fbsd.questions@rachie.is-a-geek.net) Received: from localhost (localhost [127.0.0.1]) by snoogles.rachie.is-a-geek.net (Postfix) with ESMTP id 366F91CC8B; Fri, 22 Feb 2008 07:44:07 -0900 (AKST) From: Mel To: freebsd-questions@freebsd.org Date: Fri, 22 Feb 2008 17:44:04 +0100 User-Agent: KMail/1.9.7 References: <47BD8BE3.8070209@forrie.com> <200802221345.21927.fbsd.questions@rachie.is-a-geek.net> <47BEF948.8070401@forrie.com> In-Reply-To: <47BEF948.8070401@forrie.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802221744.05717.fbsd.questions@rachie.is-a-geek.net> Cc: Forrest Aldrich Subject: Re: 6.3-STABLE Apache 2.0 uses high CPU when restarted.... X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 16:44:08 -0000 On Friday 22 February 2008 17:33:12 Forrest Aldrich wrote: > Mel wrote: > > On Friday 22 February 2008 04:26:12 Forrest Aldrich wrote: > >> Mel wrote: > >>> Your extensions.ini has duplicate and non-existing modules. Start here: > >>> > >>> mv /usr/local/etc/php/extensions.ini > >>> /usr/local/etc/php/extensions.ini.bkp sort -u > >>> /usr/local/etc/php/extensions.ini.bkp |while read MOD; do if test -f > >>> /usr/local/lib/php/20060613/${MOD##extension=}; then echo $MOD > >>> fi > >>> done >/usr/local/etc/extensions.ini > >>> php -v > >> > >> I've done this and still have a problem with PHP5 dumping core: > >> > >> root@mail /usr/ports/lang/php5]# php -v > >> > >> PHP 5.2.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 21 2008 21:51:01) > >> Copyright (c) 1997-2007 The PHP Group > >> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies > >> with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by > >> eAccelerator > >> with Suhosin v0.9.18, Copyright (c) 2002-2006, by Hardened-PHP > >> Project Segmentation fault: 11 (core dumped) > >> > >> I tried compiling this without eAccelerator, got the same problem. I'm > >> now trying it without the Suhosin enhancements to see if that's the > >> problem - sent a copy of this to the PHP5 port maintainer. > > > > Sorry, the internet is global and my pumpkin time was up. > > > > Suhosin isn't the problem. > > What the above did is make sure you have no non-existing modules loading > > and no modules twice. But the sort order was alphabetic and that's why it > > still dumps core. > > Some modules depend on eachother and one needs to be loaded before the > > other or it goes to hell. Nothing else you can do then figure out the > > correct order. Experience teaches spl, session and mysqli are common > > culprits. > > > > spl before sqlite before pdo_sqlite before session before mysqli before > > xmlreader > > > > *usually* works. > > I tried this and still having core dumps. > > This seems like an odd problem that the PHP folk might need to solve > somehow. > > There must be a way to use the php.core file to determine what's causing > it to crash... not something I've had much experience with. If I can > determine where it's crashing, then I can have a better sense of what > needs to be re-ordered. You can, if you see this: (gdb) bt #0 0x28e4fe5c in ?? () #1 0x2855bb83 in pthread_mutex_destroy () from /lib/libc.so.6 ====> #2 0x285e74fd in __tcf_1 () from /usr/local/lib/libaspell.so.16 #3 0x2855a97a in __cxa_finalize () from /lib/libc.so.6 ====> #4 0x285e6e4a in __do_global_dtors_aux () from /usr/local/lib/libaspell.so.16 #5 0x2867a204 in _fini () from /usr/local/lib/libaspell.so.16 In this case, it was the pspell module. __do_global_dtors_aux is usually the problem - destroying the globals it created. -- Mel