From owner-svn-src-all@FreeBSD.ORG Wed Dec 12 15:51:37 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECA56B14; Wed, 12 Dec 2012 15:51:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BD9B78FC12; Wed, 12 Dec 2012 15:51:37 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F39FB924; Wed, 12 Dec 2012 10:51:37 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: svn commit: r244112 - head/sys/kern Date: Wed, 12 Dec 2012 10:46:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201212110708.qBB78EWx025288@svn.freebsd.org> In-Reply-To: <201212110708.qBB78EWx025288@svn.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201212121046.43706.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 12 Dec 2012 10:51:37 -0500 (EST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 15:51:38 -0000 On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote: > Author: alfred > Date: Tue Dec 11 07:08:14 2012 > New Revision: 244112 > URL: http://svnweb.freebsd.org/changeset/base/244112 > > Log: > Cleanup more of the kassert_panic. > > fix compile warnings on !amd64 and NULL derefs that would happen > if kassert_panic() would return. This is one reason why having kassert not panic is such a bad idea. There are tons of places where the compiler knows that panic() is __dead2, and there is no cleanup code to handle what happens when an invariant is violated. This is not safe to run in the field unless your customers do not care about their data. If you are interested in doing regression tests, I am using a very different approach for some locking regression tests I am working on in p4 that allow you to use a wrapper around setjmp/longjmp to "catch" panics somewhat like exception handling in C++/Java (though much cruder). However, evne that is only intended for testing, not for production cases where production data is at stake. -- John Baldwin