php5 segfault

[Fred Condo]

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.