pleasure hearing from you Rasmus.
after observing lots of core dumps from apache, we got a different segfault and
its back trace is given bellow
#0 0x00002aaab1c46688 in ZEND_FETCH_DIM_RW_SPEC_VAR_UNUSED_HANDLER (
execute_data=0x5555714ea6c8)
at /usr/local/src/php/php-5.2.9/Zend/zend_vm_execute.h:13204
opline = (zend_op *) 0x5555714e8798
free_op1 = {var = 0x2aaaac1454fd}
#1 0x00005555714e86b8 in ?? ()
No symbol table info available.
#2 0x00002aaaac145afb in apr_pool_destroy () from /usr/lib64/libapr-1.so.0
No symbol table info available.
#3 0x000055555556a27b in suck_in_APR () from /usr/sbin/httpd
No symbol table info available.
#4 0x000055555556adf6 in main () from /usr/sbin/httpd
No symbol table info available.
we are still observing core dumps for any other issues.
--rats
________________________________
From: Rasmus Lerdorf <ras...@lerdorf.com>
To: Rathnakar Konda <rathna...@yahoo.co.in>
Cc: internals@lists.php.net
Sent: Thursday, 26 March, 2009 1:55:51 PM
Subject: Re: [PHP-DEV] problem with apache segfault
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/
Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/
