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
.....
BUGS
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...
<sigh>
> > 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....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
