You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.org> on 1998/05/08 09:54:50 UTC
thought on core dumping...
in sig_coredump we have:
ap_snprintf(emsg, sizeof(emsg),
"httpd: caught %s, attempting to dump core in %s",
s, ap_coredump_dir);
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, server_conf, emsg);
chdir(ap_coredump_dir);
abort();
exit(1);
an ap_snprintf and an ap_log_error seem like a lot to ask from an
executable in a shaky state. In fact I had a runaway earlier today, a
process failing to do an ap_get_time under ap_log_error, aftet hitting the
CGI bug which got fixed today. The problem was that it was a runaway
instead of just a death.
Maybe for 1.3.1+ - could sig_coredump instead put a flag in the scoreboard,
and the parent process would see that flag and log the core dump? Logging
the core dump is important, I agree. But getting a usable core image is
almost more important.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction brian@apache.org
brian@hyperreal.org
Re: thought on core dumping...
Posted by Dean Gaudet <dg...@arctic.org>.
Aha! Yes WCOREDUMP is in linux... it's just __WCOREDUMP (unless you also
define __USE_BSD in which case it appears as WCOREDUMP).
I'll work up a patch.
Dean
On Fri, 8 May 1998, Dean Gaudet wrote:
> Good idea. You don't need to flag it though -- the signal the child
> died on is available from waitpid().
>
> ... for standalone_main after wait_or_timeout:
>
> if (WIFSIGNALED(status)) {
> switch (WTERMSIG(status)) {
> case SIGTERM:
> case SIGHUP:
> case SIGUSR1:
> break;
> default:
> #ifdef SYS_SIGLIST
> ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE,
> "httpd: child pid %d caught signal %s (%d)",
> pid, SYS_SIGLIST[WTERMSIG(status)], WTERMSIG(status));
> #else
> ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE,
> "httpd: child pid %d caught signal %d",
> pid, WTERMSIG(status));
> #endif
> }
> }
>
> ... and add to the LINUX, and SOLARIS section2 of conf.h:
>
> #define SYS_SIGLIST _sys_siglist
>
> (and probably also all the BSD sections, and maybe the SVR4 sections...)
>
> Solaris has a WCOREDUMP(status) boolean which you can use to see if a
> coredump was attempted, so you could augment the message. I can't see
> a way to find this out in linux though, bummer -- you'd have to code up
> the list of what signals can cause coredumps.
>
> Dean
>
> On Fri, 8 May 1998, Brian Behlendorf wrote:
>
> > in sig_coredump we have:
> >
> > ap_snprintf(emsg, sizeof(emsg),
> > "httpd: caught %s, attempting to dump core in %s",
> > s, ap_coredump_dir);
> > ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, server_conf, emsg);
> > chdir(ap_coredump_dir);
> > abort();
> > exit(1);
> >
> > an ap_snprintf and an ap_log_error seem like a lot to ask from an
> > executable in a shaky state. In fact I had a runaway earlier today, a
> > process failing to do an ap_get_time under ap_log_error, aftet hitting the
> > CGI bug which got fixed today. The problem was that it was a runaway
> > instead of just a death.
> >
> > Maybe for 1.3.1+ - could sig_coredump instead put a flag in the scoreboard,
> > and the parent process would see that flag and log the core dump? Logging
> > the core dump is important, I agree. But getting a usable core image is
> > almost more important.
> >
> > Brian
> >
> >
> > --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> > pure chewing satisfaction brian@apache.org
> > brian@hyperreal.org
> >
>
>
Re: thought on core dumping...
Posted by Dean Gaudet <dg...@arctic.org>.
Good idea. You don't need to flag it though -- the signal the child
died on is available from waitpid().
... for standalone_main after wait_or_timeout:
if (WIFSIGNALED(status)) {
switch (WTERMSIG(status)) {
case SIGTERM:
case SIGHUP:
case SIGUSR1:
break;
default:
#ifdef SYS_SIGLIST
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE,
"httpd: child pid %d caught signal %s (%d)",
pid, SYS_SIGLIST[WTERMSIG(status)], WTERMSIG(status));
#else
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE,
"httpd: child pid %d caught signal %d",
pid, WTERMSIG(status));
#endif
}
}
... and add to the LINUX, and SOLARIS section2 of conf.h:
#define SYS_SIGLIST _sys_siglist
(and probably also all the BSD sections, and maybe the SVR4 sections...)
Solaris has a WCOREDUMP(status) boolean which you can use to see if a
coredump was attempted, so you could augment the message. I can't see
a way to find this out in linux though, bummer -- you'd have to code up
the list of what signals can cause coredumps.
Dean
On Fri, 8 May 1998, Brian Behlendorf wrote:
> in sig_coredump we have:
>
> ap_snprintf(emsg, sizeof(emsg),
> "httpd: caught %s, attempting to dump core in %s",
> s, ap_coredump_dir);
> ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_NOTICE, server_conf, emsg);
> chdir(ap_coredump_dir);
> abort();
> exit(1);
>
> an ap_snprintf and an ap_log_error seem like a lot to ask from an
> executable in a shaky state. In fact I had a runaway earlier today, a
> process failing to do an ap_get_time under ap_log_error, aftet hitting the
> CGI bug which got fixed today. The problem was that it was a runaway
> instead of just a death.
>
> Maybe for 1.3.1+ - could sig_coredump instead put a flag in the scoreboard,
> and the parent process would see that flag and log the core dump? Logging
> the core dump is important, I agree. But getting a usable core image is
> almost more important.
>
> Brian
>
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> pure chewing satisfaction brian@apache.org
> brian@hyperreal.org
>