From owner-freebsd-arch@FreeBSD.ORG  Sat Jun 11 15:46:33 2005
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
X-Original-To: freebsd-arch@freebsd.org
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0B02016A41C
	for <freebsd-arch@freebsd.org>; Sat, 11 Jun 2005 15:46:33 +0000 (GMT)
	(envelope-from bakul@bitblocks.com)
Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B69BF43D1D
	for <freebsd-arch@freebsd.org>; Sat, 11 Jun 2005 15:46:32 +0000 (GMT)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (localhost [127.0.0.1])
	by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j5BFkToq011515;
	Sat, 11 Jun 2005 08:46:29 -0700 (PDT)
	(envelope-from bakul@bitblocks.com)
Message-Id: <200506111546.j5BFkToq011515@gate.bitblocks.com>
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-reply-to: Your message of "Sat, 11 Jun 2005 09:22:45 +0200."
	<1078.1118474565@critter.freebsd.dk> 
Date: Sat, 11 Jun 2005 08:46:29 -0700
From: Bakul Shah <bakul@BitBlocks.com>
Cc: Antoine Brodin <antoine.brodin@laposte.net>, freebsd-arch@freebsd.org
Subject: Re: RFC: Stack saving/tracing functionality. 
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jun 2005 15:46:33 -0000

> ... but it would be neat if it could also save/print userland stacks
> so that we could get tracebacks from abort()'ing userland programs.

Along these lines; wouldn't it be neat if there was a sysctl
to leave a segfaulted or aborted process around so that you
can attach a debugger to it and find out what went wrong (and
may be even correct it!)?  Debugging a live process (even if
fatally injured) yields more clues as you can poke around at
its I/O connections, its caller process etc.  A separate
program can be used to create a coredump if you really wish
to preseve the dead body for later autopsy.