From owner-freebsd-questions@FreeBSD.ORG Sun Oct 7 16:28:00 2007 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 29EED16A418 for ; Sun, 7 Oct 2007 16:28:00 +0000 (UTC) (envelope-from rsecor@seqlogic.com) Received: from dpe2600.seqlogic.net (dpe2600.seqlogic.net [208.72.157.30]) by mx1.freebsd.org (Postfix) with ESMTP id DD0D113C48D for ; Sun, 7 Oct 2007 16:27:59 +0000 (UTC) (envelope-from rsecor@seqlogic.com) Received: (qmail 11743 invoked by uid 89); 7 Oct 2007 12:28:12 -0400 Received: from adsl-065-013-079-217.sip.bct.bellsouth.net (HELO ?10.1.1.102?) (rsecor@seqlogic.com@65.13.79.217) by dpe2600.seqlogic.net with SMTP; 7 Oct 2007 12:28:12 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <200710062125.12436.fbsd.questions@rachie.is-a-geek.net> References: <200710062125.12436.fbsd.questions@rachie.is-a-geek.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Richard Secor Date: Sun, 7 Oct 2007 12:27:55 -0400 To: freebsd-questions@freebsd.org X-Mailer: Apple Mail (2.752.3) Subject: Re: Problem with PHP cli core dumping (SOLVED) 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: Sun, 07 Oct 2007 16:28:00 -0000 On Oct 6, 2007, at 3:25 PM, Mel wrote: > On Wednesday 03 October 2007 18:54:54 Richard Secor wrote: >> On Wed, 26 Sep 2007, Mel wrote: >>>> On Tuesday 25 September 2007 18:50:39 Derrick wrote: >>>>> On Tue, 25 Sep 2007, Eric wrote: >>>>>> Derrick wrote: >>>>>>> so it's sessions.so >>>>>>> I've tried rebuilding it, but still has the same issue. >>>> >>>> Move session to indicated spot, then try php -v again. If it >> >> still coredumps, >> >>>> move above spl. If it still coredumps, move it up one spot and >> >> rerun, till it >> >>>> stops coredumping. >>>> >>>> The bug is in the general extension destructor and changing the >> >> order till it >> >>>> works is the only remedy. >>> >>> Thanks to all those that input some output. >>> >>> I moved extension=session.so to the start of the file after >>> trying the >>> first couple suggestions, and all is working now.. >> >> I had this problem, however, after changing the file around I'm >> still getting core dumps. >> I find that this happens whenever I upgrade from the port :( >> Anyway, it seems I'm getting the dumps from spl.so (it's fine if I >> comment it and anything that depends on it). >> I've tried putting it in every line of the extension file but it >> still dumps out. >> I've tried completely rebuilding all of php and all associated >> extensions, still dumps out. > > It's not spl itself that needs to be moved. There's extensions that > are > required to be loaded *before* spl and most likely others. > > You can speed things up as follows: > php -i >/dev/null 2>&1 > gdb -core ./php.core -exec `which php` > > [snip symbol loading] > > (gdb) bt > #0 0x00000000 in ?? () > #1 0x28e90544 in __do_global_dtors_aux () > from /usr/local/lib/php/20060613/simplexml.so > ^^^^^^^^^^^^ > > That's the one that needs to be moved up. > > -- > Mel > X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on > dpe2600.seqlogic.net > X-Spam-Level: > X-Spam-Status: No, score=0.1 required=5.0 tests=RDNS_NONE autolearn=no > version=3.2.3 > Received: (qmail 75177 invoked by uid 98); 6 Oct 2007 15:25:44 -0400 > Received: from 66.230.99.27 by dpe2600.seqlogic.net (envelope-from > , uid 89) with qmail-scanner-2.01 > (clamdscan: 0.91.2/4339. spamassassin: 3.2.3. > Clear:RC:0(66.230.99.27):SA:0(0.1/5.0):. > Processed in 8.284415 secs); 06 Oct 2007 19:25:44 -0000 > Received: from unknown (HELO snoogles.rachie.is-a-geek.net) > (66.230.99.27) > by dpe2600.seqlogic.net with SMTP; 6 Oct 2007 15:25:35 -0400 > Received: from localhost (localhost [127.0.0.1]) > by snoogles.rachie.is-a-geek.net (Postfix) with ESMTP id 877A71CDEE; > Sat, 6 Oct 2007 11:25:15 -0800 (AKDT) > From: Mel > To: freebsd-questions@freebsd.org > Subject: Re: Problem with PHP cli core dumping (SOLVED) > Date: Sat, 6 Oct 2007 21:25:11 +0200 > User-Agent: KMail/1.9.7 > Cc: Richard Secor > References: > In-Reply-To: > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > Message-Id: <200710062125.12436.fbsd.questions@rachie.is-a-geek.net> > > On Wednesday 03 October 2007 18:54:54 Richard Secor wrote: >> On Wed, 26 Sep 2007, Mel wrote: >>>> On Tuesday 25 September 2007 18:50:39 Derrick wrote: >>>>> On Tue, 25 Sep 2007, Eric wrote: >>>>>> Derrick wrote: >>>>>>> so it's sessions.so >>>>>>> I've tried rebuilding it, but still has the same issue. >>>> >>>> Move session to indicated spot, then try php -v again. If it >> >> still coredumps, >> >>>> move above spl. If it still coredumps, move it up one spot and >> >> rerun, till it >> >>>> stops coredumping. >>>> >>>> The bug is in the general extension destructor and changing the >> >> order till it >> >>>> works is the only remedy. >>> >>> Thanks to all those that input some output. >>> >>> I moved extension=session.so to the start of the file after >>> trying the >>> first couple suggestions, and all is working now.. >> >> I had this problem, however, after changing the file around I'm >> still getting core dumps. >> I find that this happens whenever I upgrade from the port :( >> Anyway, it seems I'm getting the dumps from spl.so (it's fine if I >> comment it and anything that depends on it). >> I've tried putting it in every line of the extension file but it >> still dumps out. >> I've tried completely rebuilding all of php and all associated >> extensions, still dumps out. > > It's not spl itself that needs to be moved. There's extensions that > are > required to be loaded *before* spl and most likely others. > > You can speed things up as follows: > php -i >/dev/null 2>&1 > gdb -core ./php.core -exec `which php` > > [snip symbol loading] > > (gdb) bt > #0 0x00000000 in ?? () > #1 0x28e90544 in __do_global_dtors_aux () > from /usr/local/lib/php/20060613/simplexml.so > ^^^^^^^^^^^^ > > That's the one that needs to be moved up. > > -- > Mel Why doesn't PHP check for dependency and give you error messages letting you know (or at least map around somehow)? I hope they change this so it makes more sense. -Rich