Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.146.177 cause and error)
Message-ID: <49CB3C0F.8090908@lerdorf.com>
Date: Thu, 26 Mar 2009 01:25:51 -0700
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Rathnakar Konda <rathnacar@yahoo.co.in>
CC: internals@lists.php.net
References: <91365.8780.qm@web8604.mail.in.yahoo.com>
In-Reply-To: <91365.8780.qm@web8604.mail.in.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] problem with apache segfault
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Note that your backtrace doesn't touch PHP at all.  It is entirely in
Apache land and it is a crash on a graceful shutdown.

-Rasmus

Rathnakar Konda wrote:
> Hi Guys,
> 
> We are have a problem with apache segfault on our production server. Please read bellow for description.
> 
> Its
> a web application written in php5 and implemented most of the oop
> concepts and lot of regular expressions, curl, mcrypt, simplexml,
> mssql, exceptions and user defined error handlers. When we run this app
> on our test server, we had no problems, but when we moved it on to the
> production(here we used have big amount of traffic), initially we saw
> no problems from our end user testing but from system log, we saw lots
> of 'segfaults' and thus requests were being dropped(difference in
> traffic).
> 
> Weird thing is that, on the same apache httpd, there
> is an another application running successfully which is having lesser
> oop concepts but with same libraries. We are running these two
> applications with virtual host concept. We see 'segfaults' only when
> the traffic is very high on the first application.
> 
> We have upgraded our php module from 5.2.6 to 5.2.9 but with no result. We have the core dump of the apache below:
> 
> #0  0x000055555557dfee in ap_merge_per_dir_configs () from /usr/sbin/httpd
> No symbol table info available.
> #1  0x000055555557b121 in ap_directory_walk () from /usr/sbin/httpd
> No symbol table info available.
> #2  0x00005555555765b9 in ap_is_recursion_limit_exceeded () from /usr/sbin/httpd
> No symbol table info available.
> #3  0x0000555555578b42 in ap_run_map_to_storage () from /usr/sbin/httpd
> No symbol table info available.
> #4  0x0000555555579cbc in ap_process_request_internal () from /usr/sbin/httpd
> No symbol table info available.
> #5  0x000055555558b668 in ap_process_request () from /usr/sbin/httpd
> No symbol table info available.
> #6  0x0000555555588900 in ap_register_input_filter () from /usr/sbin/httpd
> No symbol table info available.
> #7  0x0000555555584a92 in ap_run_process_connection () from /usr/sbin/httpd
> No symbol table info available.
> #8  0x000055555558f27b in ap_graceful_stop_signalled () from /usr/sbin/httpd
> No symbol table info available.
> #9  0x000055555558f50a in ap_graceful_stop_signalled () from /usr/sbin/httpd
> No symbol table info available.
> #10 0x000055555558fd7b in ap_mpm_run () from /usr/sbin/httpd
> No symbol table info available.
> #11 0x000055555556ade4 in main () from /usr/sbin/httpd
> No symbol table info available.
> 
> We
> have tried modifying most of the curl implementation but with no use.
> Also now we have no clues of the origin of the bug. Any kind of help
> regarding this is mostly appreciated.
> 
> THANK YOU
> --rats
> 
> 
> 
>       Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/