From owner-freebsd-current Sun Mar 16 17:26:42 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1218E37B401 for ; Sun, 16 Mar 2003 17:26:41 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F8B543FA3 for ; Sun, 16 Mar 2003 17:26:40 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 8BEC95308; Mon, 17 Mar 2003 02:26:37 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: walt Cc: freebsd-current@freebsd.org Subject: Re: Why did INVARIANTS hide the geom bug? From: des@ofug.org (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Mon, 17 Mar 2003 02:26:37 +0100 In-Reply-To: <3E74BEA3.6070603@myrealbox.com> (walt's message of "Sun, 16 Mar 2003 10:12:51 -0800") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 References: <3E74BEA3.6070603@myrealbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG walt writes: > If inclusion of INVARIANTS serves to disguise bugs in > the kernel, I wonder if kernel committers should be > using this option routinely? It doesn't "serve to disguise bugs"; quite to the contrary, it serves to expose bugs and reveal their causes. However, INVARIANTS is slightly invasive; it adds code to the kernel, and in some cases changes data structures a little, and these changes have subtle side effects which may cause a bug to go into hiding. Such bugs are called "heisenbugs" (because the presence of the observer affects the outcome of the experiment...) and are generally caused by using a stack variable before its initialization, or dereferencing a pointer after freeing the memory it points to, etc. I recently fixed a bug in pkg_delete which had gone undetected for years because it depended on whether the stack had been used before the function the bug was in got called, and even if it had the garbage on the stack would in most cases be recognized as an incorrect value and ignored, but once in a while pkg_delete thought it was a valid file name and ended up doing the weirdest things. Running pkg_delete with kernel tracing enabled (which would have shown me exactly what pkg_delete was trying to do) caused the bug to magically disappear - I never quite figured out why - so I had a hell of a time tracking it down. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message