X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,FH_DATE_PAST_20XX autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id o15LDlAT161896 for ; Fri, 5 Feb 2010 15:13:47 -0600 X-ASG-Debug-ID: 1265404497-133402180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 870891C8D607 for ; Fri, 5 Feb 2010 13:14:57 -0800 (PST) Received: from mail.sandeen.net (64-131-60-146.usfamily.net [64.131.60.146]) by cuda.sgi.com with ESMTP id 0VBlrhgJjtOsyToy for ; Fri, 05 Feb 2010 13:14:57 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 50679124CF07; Fri, 5 Feb 2010 15:14:57 -0600 (CST) Message-ID: <4B6C8A50.6090108@sandeen.net> Date: Fri, 05 Feb 2010 15:14:56 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dave Chinner CC: xfs mailing list X-ASG-Orig-Subj: Re: xfsprogs: to -DDEBUG or not to -DDEBUG? Subject: Re: xfsprogs: to -DDEBUG or not to -DDEBUG? References: <4B6AFB83.1070309@sandeen.net> <20100205023134.GA11483@discord.disaster> In-Reply-To: <20100205023134.GA11483@discord.disaster> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-60-146.usfamily.net[64.131.60.146] X-Barracuda-Start-Time: 1265404498 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.21750 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dave Chinner wrote: > On Thu, Feb 04, 2010 at 10:53:23AM -0600, Eric Sandeen wrote: >> Fedora, long ago, disabled debug in the xfsprogs specfile: >> >> http://cvs.fedoraproject.org/viewvc/F-12/xfsprogs/xfsprogs.spec?r1=1.5&r2=1.6 >> >> * Wed Apr 20 2005 Dave Jones >> - Disable debug. (#151438) >> >> per this bug: https://bugzilla.redhat.com/show_bug.cgi?id=151438 >> >> referencing this email thread: >> >> http://oss.sgi.com/archives/linux-xfs/2005-03/msg00038.html >> which no longer exists (grrrr) but is probably now here: >> >> http://oss.sgi.com/archives/xfs/2005-03/msg00416.html >> >> Fedora still builds with -DNDEBUG, but the upstream tarball has >> it on by default. I have seen several occasions where other >> distros had failing xfs_repairs which were "fixed" by disabling >> debug. I'd like to make a decision on whether DEBUG should be >> on or off by default for upstream releases. Any thoughts? > > Personally I'd prefer the repair process to stop if it comes across > inconsistencies it can't handle. Ignoring them is as likely to "fix" > the crash as it is to corrupt the filesystem more. > > On top of that we get bug reports when those problems are hit so > we can look into what caused the problem. We don't really have a > repair test suite that covers all the possible corruptions that > can occur, so we are kind of reliant on users reporting conditions > we've never had to handle before so we can fix them... > > Cheers, > > Dave. Hrm. Well, that makes sense. OTOH, Debian turns it off too: $ grep DEBUG debian/rules options = export DEBUG=-DNDEBUG DISTRIBUTION=debian \ and for some reason when I take this out of the Fedora specfile, it fails to build because: xfs_bmap.c:23: warning: 'xfs_bmap_check_leaf_extents' used but never defined and indeed there is a forward declaration: #ifdef DEBUG STATIC void xfs_bmap_check_leaf_extents(xfs_btree_cur_t *cur, xfs_inode_t *ip, int whichfork); #endif but no definition that I can find .... Something must be odd w/ the way this flag works though because a simple "make" in the git tree, w/o any -DNDEBUG, works fine for me ... Meanwhile I'm leaving DEBUG=-DNDEBUG on in Fedora just for now :) -Eric