Date: Wed, 8 Oct 2008 12:50:53 -0700 From: Fred Condo <fcondo@quinn.com> To: nightrecon@verizon.net Cc: freebsd-questions@freebsd.org Subject: Re: php5 segfault Message-ID: <EA000AF4-02F5-4515-9257-48736A51B4B8@quinn.com> In-Reply-To: <gcirs1$iak$1@ger.gmane.org> References: <48ECACB4.8080103@shopzeus.com> <20081008131248.GA77388@icarus.home.lan> <gcirs1$iak$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 8, 2008, at 10:53 AM, Michael Powell wrote: > Jeremy Chadwick wrote: > >> On Wed, Oct 08, 2008 at 02:51:00PM +0200, Laszlo Nagy wrote: > [snip] >>> >>> So it is using -O2 and -pipe. Is this something that I can disable? >> >> If you want. "make config" in /usr/ports/lang/php5 will give you a >> menu option for DEBUG; turn it on. >> >> I'm not sure what the compile options you're showing have >> *anything* to >> do with the segfault you're reporting. I don't see any backtraces or >> details of the segfault. > > I've used -pipe -O2 for years and never had it cause me trouble. > >>> It might be because we are using postgresql connections. For pages >>> without pgsql connection, there is no segfault. > > Still using MySQL so I can't speak to PostgreSQL PHP connectivity. > >> I've personally used PHP5 (as a CGI only, not as an Apache module) >> with PostgreSQL and experienced no segfaults. >> >>> It must be noted that the segfault happens on cleanup. E.g. all web >>> sites are working fine, except that we are getting many many >>> segfault >>> messages in the logs all the time. > > This will inhibit performance. The ones that are failing are having > the > script(s) restarted. If you can fix this performance will improve. > >> Many people have found that re-ordering the "extensions" lines in >> /usr/local/etc/php/extensions.ini has solved odd segfaults. I >> personally have never seen this, nor have ever needed to adjust that >> file, but it has worked for others. > > One quickie shortcut to try as experimentation is to just comment out > hash.so in extensions.ini. I have had trouble with this one, ie to the > extent Apache wouldn't even start. > > I've read/heard about the reorder thing too and never needed it. > What I > suspect is there is a possibility that what happened is people went in > after the fact and installed xyz extensions after the first main > install > after discoverring they forgot or left out something they needed. This > results in the line(s) just getting tacked on at the bottom. If they > had > wiped all PHP and done it again from scratch the list in > extensions.ini > would then be correct. Only a theory on my part. > >> Also, you cannot use a threaded Apache (e.g. threaded MPMs) with PHP >> since not all extensions support threading. Your Apache needs to be >> built without threads and use a non-thread model (e.g. prefork). >> I've >> also had success with Apache-ITK-mpm. > > This is very true for mod_php, but less so if PHP is run as FastCGI. > I am > currently running a box at work with the event mpm and mod_fcgid for > testing and it seems to be doing well. YMMV > >> Search the mailing lists for this situation, try the recommendations, >> and then if nothing fixes it, provide a backtrace. >> > > The normal default of error_reporting = E_ALL & ~E_NOTICE is > present, but if > you want it to log to it's own file uncomment ;error_log = filename > (or > syslog if you prefer). You may need to do a 'touch on the <filename> > and > make it's permissions match those the webserver runs under. > > If things get really bad take a look at http://www.xdebug.org/ > I don't think this really belongs on a production machine (IMHO), > but I have > used it on my development server. Better as a last ditch effort > probably. > > -Mike Have a look at http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround PHP extensions have to be loaded in a particular order to avoid the segfaults at cleanup.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA000AF4-02F5-4515-9257-48736A51B4B8>