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:
> >>
> >> [EMAIL PROTECTED] /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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to