httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: big problem on SunOS
Date Tue, 05 Dec 1995 16:38:57 GMT
In reply to sameer who said
> 
> > 
> > You can't control where core dumps go, they always go into the processes
> > current working directory. 

Unless of course you have a signal handler that catches them :-)
I'm not sure this is such a good idea actually but maybe someone can
re-assure me.

Depending on the reason for the SEGV in the first place, continuing
processing could be a very dumb thing to do. The signal handler doesn't
just try and go somewhere nice to dump core, it writes to the log files
as well. I wonder what would happen if that's what causes the SEGV in the
first place? Also, the core dump is not going to represent the state at the
time of the SEGV and may not be of much use for diagnosis. Trapping
SEGV just so that you can dump the core file into a particular
directory doesn't seem to have any advantages that outweigh my
eoncerns. If you've SEGV'd then you've got badly broken code and the thing
to do is just dump core and die. I haven't used an Apache core dump for
debugging purposes but I'd have thought that the top of the stack is
going to have all sorts of calls on it from the signal handler and the
core dump will be due to SIGABRT and not SIGSEGV.

> 
> 	The apache SEGV handler:
> 
> void seg_fault() {
>     log_error("httpd: caught SIGSEGV, dumping core", server_conf);
>     chdir(server_root);
>     abort();
>     exit(1);
> }


Another config flag I guess.


-- 
  Paul Richards. Originative Solutions Ltd.
  Internet: paul@netcraft.co.uk, http://www.netcraft.co.uk
  Phone: 0370 462071 (Mobile), +44 1225 447500 (work)

Mime
View raw message