Date: Wed, 08 Oct 2008 13:53:49 -0400 From: Michael Powell <nightrecon@verizon.net> To: freebsd-questions@freebsd.org Subject: Re: php5 segfault Message-ID: <gcirs1$iak$1@ger.gmane.org> References: <48ECACB4.8080103@shopzeus.com> <20081008131248.GA77388@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gcirs1$iak$1>