Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.co.in from 202.43.219.77 cause and error)
DomainKey-Status: good
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.co.in;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
  b=Ef88Y5DnXDyhMW0Ohw5XH6XVjM8Fl78iLTfzh+ZUl6wkh4MO1F7niPcRftz+hcIKcQOH4+ak4AMO9+dd/37lhHvsGLNjh0n4GFzpkglEovZzJdyAMVnBYyyXx24HdXrQ7toeYeB6I0+BfPzugAbzItk1bG5MUi/iiD2I6AnpVuQ=;
Message-ID: <798982.8787.qm@web8602.mail.in.yahoo.com>
References: <91365.8780.qm@web8604.mail.in.yahoo.com> <49CB3C0F.8090908@lerdorf.com>
Date: Thu, 26 Mar 2009 14:11:24 +0530 (IST)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: internals@lists.php.net
In-Reply-To: <49CB3C0F.8090908@lerdorf.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-642677516-1238056884=:8787"
Subject: Re: [PHP-DEV] problem with apache segfault
From: rathnacar@yahoo.co.in (Rathnakar Konda)

--0-642677516-1238056884=:8787
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

pleasure hearing from you Rasmus.=0A=0Aafter observing lots of core dumps f=
rom apache, we got a different segfault and its back trace is given bellow=
=0A=0A#0  0x00002aaab1c46688 in ZEND_FETCH_DIM_RW_SPEC_VAR_UNUSED_HANDLER (=
=0A    execute_data=3D0x5555714ea6c8)=0A    at /usr/local/src/php/php-5.2.9=
/Zend/zend_vm_execute.h:13204=0A        opline =3D (zend_op *) 0x5555714e87=
98=0A        free_op1 =3D {var =3D 0x2aaaac1454fd}=0A#1  0x00005555714e86b8=
 in ?? ()=0ANo symbol table info available.=0A#2  0x00002aaaac145afb in apr=
_pool_destroy () from /usr/lib64/libapr-1.so.0=0ANo symbol table info avail=
able.=0A#3  0x000055555556a27b in suck_in_APR () from /usr/sbin/httpd=0ANo =
symbol table info available.=0A#4  0x000055555556adf6 in main () from /usr/=
sbin/httpd=0ANo symbol table info available.=0A=0Awe are still observing co=
re dumps for any other issues.=0A=0A--rats=0A=0A=0A=0A_____________________=
___________=0AFrom: Rasmus Lerdorf <rasmus@lerdorf.com>=0ATo: Rathnakar Kon=
da <rathnacar@yahoo.co.in>=0ACc: internals@lists.php.net=0ASent: Thursday, =
26 March, 2009 1:55:51 PM=0ASubject: Re: [PHP-DEV] problem with apache segf=
ault=0A=0ANote that your backtrace doesn't touch PHP at all.  It is entirel=
y in=0AApache land and it is a crash on a graceful shutdown.=0A=0A-Rasmus=
=0A=0ARathnakar Konda wrote:=0A> Hi Guys,=0A> =0A> We are have a problem wi=
th apache segfault on our production server. Please read bellow for descrip=
tion.=0A> =0A> Its=0A> a web application written in php5 and implemented mo=
st of the oop=0A> concepts and lot of regular expressions, curl, mcrypt, si=
mplexml,=0A> mssql, exceptions and user defined error handlers. When we run=
 this app=0A> on our test server, we had no problems, but when we moved it =
on to the=0A> production(here we used have big amount of traffic), initiall=
y we saw=0A> no problems from our end user testing but from system log, we =
saw lots=0A> of 'segfaults' and thus requests were being dropped(difference=
 in=0A> traffic).=0A> =0A> Weird thing is that, on the same apache httpd, t=
here=0A> is an another application running successfully which is having les=
ser=0A> oop concepts but with same libraries. We are running these two=0A> =
applications with virtual host concept. We see 'segfaults' only when=0A> th=
e traffic is very high on the first application.=0A> =0A> We have upgraded =
our php module from 5.2.6 to 5.2.9 but with no result. We have the core dum=
p of the apache below:=0A> =0A> #0  0x000055555557dfee in ap_merge_per_dir_=
configs () from /usr/sbin/httpd=0A> No symbol table info available.=0A> #1 =
 0x000055555557b121 in ap_directory_walk () from /usr/sbin/httpd=0A> No sym=
bol table info available.=0A> #2  0x00005555555765b9 in ap_is_recursion_lim=
it_exceeded () from /usr/sbin/httpd=0A> No symbol table info available.=0A>=
 #3  0x0000555555578b42 in ap_run_map_to_storage () from /usr/sbin/httpd=0A=
> No symbol table info available.=0A> #4  0x0000555555579cbc in ap_process_=
request_internal () from /usr/sbin/httpd=0A> No symbol table info available=
.=0A> #5  0x000055555558b668 in ap_process_request () from /usr/sbin/httpd=
=0A> No symbol table info available.=0A> #6  0x0000555555588900 in ap_regis=
ter_input_filter () from /usr/sbin/httpd=0A> No symbol table info available=
.=0A> #7  0x0000555555584a92 in ap_run_process_connection () from /usr/sbin=
/httpd=0A> No symbol table info available.=0A> #8  0x000055555558f27b in ap=
_graceful_stop_signalled () from /usr/sbin/httpd=0A> No symbol table info a=
vailable.=0A> #9  0x000055555558f50a in ap_graceful_stop_signalled () from =
/usr/sbin/httpd=0A> No symbol table info available.=0A> #10 0x000055555558f=
d7b in ap_mpm_run () from /usr/sbin/httpd=0A> No symbol table info availabl=
e.=0A> #11 0x000055555556ade4 in main () from /usr/sbin/httpd=0A> No symbol=
 table info available.=0A> =0A> We=0A> have tried modifying most of the cur=
l implementation but with no use.=0A> Also now we have no clues of the orig=
in of the bug. Any kind of help=0A> regarding this is mostly appreciated.=
=0A> =0A> THANK YOU=0A> --rats=0A> =0A> =0A> =0A>       Check out the all-n=
ew Messenger 9.0! Go to http://in.messenger.yahoo.com/=0A=0A=0A      Check =
out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/
--0-642677516-1238056884=:8787--