Problem with PHP cli core dumping (SOLVED)

Richard Secor rsecor at seqlogic.com
Sun Oct 7 09:28:00 PDT 2007


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  
> <fbsd.questions at rachie.is-a-geek.net>, 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 <fbsd.questions at rachie.is-a-geek.net>
> To: freebsd-questions at 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 <rsecor at seqlogic.com>
> References: <C85CDD58-FE89-41B9-BEA0-3C964DC55E40 at seqlogic.com>
> In-Reply-To: <C85CDD58-FE89-41B9-BEA0-3C964DC55E40 at seqlogic.com>
> 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 at 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



More information about the freebsd-questions mailing list