From owner-cvs-all@FreeBSD.ORG Thu Apr 12 01:47:25 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3690916A400; Thu, 12 Apr 2007 01:47:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2199713C457; Thu, 12 Apr 2007 01:47:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 79C6F1A4D82; Wed, 11 Apr 2007 18:47:32 -0700 (PDT) Date: Wed, 11 Apr 2007 18:47:32 -0700 From: Alfred Perlstein To: Dag-Erling Sm?rgrav Message-ID: <20070412014732.GM2382@elvis.mu.org> References: <200704100403.l3A43ZnL057659@repoman.freebsd.org> <88607eb20704101217x4e3c81f9xf914f7da7714daf8@mail.gmail.com> <20070411195935.GA2382@elvis.mu.org> <88607eb20704111346q5c463b60w2547084231a11227@mail.gmail.com> <20070411220228.GG2382@elvis.mu.org> <86abxemt1a.fsf@dwp.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86abxemt1a.fsf@dwp.des.no> User-Agent: Mutt/1.4.2.2i Cc: Ed Maste , cvs-src@freebsd.org, src-committers@freebsd.org, Xin LI , cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.bin/truss Makefile amd64-fbsd.c extern.h i386-fbsd.c i386-linux.c ia64-fbsd.c main.c powerpc-fbsd.c setup.c sparc64-fbsd.c syscall.h syscalls.c truss.1 truss.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 01:47:25 -0000 * Dag-Erling Sm?rgrav [070411 15:43] wrote: > Alfred Perlstein writes: > > Ed Maste [070411 13:46] wrote: > > > Currently, without the -s option the core produced by gcore is > > > inconsistent, and it's that behaviour that would be eliminated with my > > > change. Do you actually have a use for inconsistent core files? > > Not so much as a need for an inconsistent core so much as a need > > for a core without halting the program for the time it takes to > > dump core. > > What Ed is trying to tell you is that the result will be a useless > core file. And what I'm trying to say is that he's wrong. One can still examine such a corefile to find valuable data. -- - Alfred Perlstein