From owner-svn-src-head@FreeBSD.ORG Thu Dec 13 06:47:51 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E98084BB; Thu, 13 Dec 2012 06:47:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 319D58FC08; Thu, 13 Dec 2012 06:47:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA11155; Thu, 13 Dec 2012 08:47:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Tj2aC-000MmZ-3L; Thu, 13 Dec 2012 08:47:48 +0200 Message-ID: <50C97A11.10409@FreeBSD.org> Date: Thu, 13 Dec 2012 08:47:45 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r244112 - head/sys/kern References: <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org> <201212121658.49048.jhb@freebsd.org> <50C90567.8080406@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Alfred Perlstein , src-committers@FreeBSD.org, John Baldwin X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 06:47:52 -0000 on 13/12/2012 00:38 Adrian Chadd said the following: > There are two parts to this; > > * don't compile in invariants. Panics panic. Invariant conditions > aren't checked. You end up with data corruption still if there are > bugs. > * compile in invariants. Panics panic. Invariant conditions are > checked and immediately panic. You can't run this in production to get > debugging info because our debugging info is "create a crash dump and > reboot." > > Now, the crash dump is great for us developers. But crap for say, a > file server. If it's some very subtle issue that only occasionally > pops up once a week and doesn't obviously screw with your data: > > * you can enable invariants and get a crash dump each time - then us > developers get lots of information, but the user experiences outages > once a week; > * they just give the hell up, disable invariants in production and > occasionally hit odd issues they can't explain. > > So now there's a third option: > > * enable invariants, get told when you hit that condition, and continue running. > > Now, we ship _right now_ generic with INVARIANTS disabled, because in > theory the releases are supposed to be stable enough for us not to > need the extra debugging information. That means that for those very > occasional, very subtle bugs that invariants may catch, we don't have > any way of getting told about them. > > Now, enabling some alternative to panic() is a different story and not > what's being addressed here. > > HTH, Let me see if it does... So basically a violated assertion means that something has already gone wrong. With assertions you catch that sooner and get full debug information and can fix it. Without assertions you crash anyway (in 99% cases), but later and get much less useful information. Now you have an option to crash later while having the worse performance and the only benefit is a log message which may or may not be useful for debugging. No, this doesn't help. -- Andriy Gapon