httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: correlating segmentation fault to the request
Date Wed, 07 Aug 2002 23:51:39 GMT
I was actually talking to one of the other developers about this problem
earlier this week.  It would technically be possible to write a module
that logs the request and all of the headers as it is being served.  The
problem with doing this, is that it will actually be hard to do the
correlation that you want to do on a heavily loaded server.  That should
be clear if you consider that you may have 100 concurrent requests, in
100 different processes.  Trying to figure out which request caused the
seg fault is going to be daunting.

 

A better way to solve this problem, IMHO, is to generate a core file
from the Apache that is seg faulting, and then look at the core file
with gdb (or some other debugger).  This will let you see not only the
headers, but potentially, exactly where in the request processing you
were when the process died.

 

Ryan

----------------------------------------------
Ryan Bloom
rbb@covalent.net           rbb@apache.org

-----Original Message-----
From: Kevin Schmidgall [mailto:kevin.schmidgall.c2e1@statefarm.com] 
Sent: Thursday, August 08, 2002 8:00 AM
To: users@httpd.apache.org
Subject: correlating segmentation fault to the request

 

Periodically we receive a segmentation fault on one of the httpd
servers.  The error message along with the timestamp and PID are logged
in the error log, but I know of no way to determine what request was
being served at the time (in order to at least try to recreate the
problem).

Is there a way to temporarily have apache log the request _prior_ to
handling it?  That way we could correlate the PID between the error and
access logs.  Or are there other methods for pinpointing the root cause
of these segmentation faults?


Mime
View raw message