[Top] [All Lists]

Re: [ANNOUNCE] xfsprogs: v3.2.0 released!

To: Adam Sampson <ats@xxxxxxxxx>
Subject: Re: [ANNOUNCE] xfsprogs: v3.2.0 released!
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 19 May 2014 12:55:53 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <y2a4n0o1xt7.fsf@xxxxxxxxxxxxxxxxxxxx>
References: <20140516055650.GF26353@dastard> <y2a8uq11g5k.fsf@xxxxxxxxxxxxxxxxxxxx> <20140517002309.GA18954@dastard> <y2a4n0o1xt7.fsf@xxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sat, May 17, 2014 at 11:53:08AM +0100, Adam Sampson wrote:
> Dave Chinner <david@xxxxxxxxxxxxx> writes:
> > [...] it's preferable to have things like xfs_repair abort when it
> > comes across an inconsistency it can't handle than to continue blindly
> > along and making a bigger mess of the filesystem it's supposed to be
> > fixing...
> Yes -- that's why I was building with DEBUG= on previous releases
> (i.e. I want assertions enabled). doc/INSTALL says that DEBUG=-DNDEBUG
> disables assertions, so packagers are quite likely to have DEBUG= in
> their build process.

Hmmm - so, not being an everyday userspace programmer, it didn't
even occur to me that "-DNDEBUG" actually changes libc header
behaviour, not anything to do with the XFS code.

$ man assert
       assert()  is  implemented as a macro; if the expression
       tested has side-effects, program behavior will be different
       depending on whether NDEBUG is defined.  This may create
       Heisenbugs which go away when debugging is turned on.

Yup, it's oh so obvious now that "NDEBUG" is something owned by
system library code, not the xfsprogs package...


> > Anyway, we'll look to fix it for 3.2.1.

Or maybe not. The intent of always turning off the asserts is that
code like xfs_repair shouldn't assert fail when stuff it detected as
out of bounds in a library function. IOWs, you're quite likely to
unintentionally break repair by removing the NDEBUG define to
re-instate the library asserts...

The control of the assert statements in the xfs_repair code itself
is handled by the -DDEBUG macro, which is configurable. i.e. you can
chose whether or not to have asserts in the repair code itself for
it to fail when an inconsistency it can't handle is detected, but
repair defines "inconsistent and cannot continue" very differently
to the libxfs library code....


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>