Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 14315 invoked by uid 6000); 8 May 1998 07:59:19 -0000 Received: (qmail 14305 invoked by uid 24); 8 May 1998 07:59:17 -0000 Message-Id: <3.0.3.32.19980508005450.008d82b0@hyperreal.org> X-Sender: brian@hyperreal.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 08 May 1998 00:54:50 -0700 To: new-httpd@apache.org From: Brian Behlendorf Subject: thought on core dumping... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org 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