From: Dave Chinner <david@fromorbit.com>
To: Adam Sampson <ats@offog.org>
Cc: xfs@oss.sgi.com
Subject: Re: [ANNOUNCE] xfsprogs: v3.2.0 released!
Date: Mon, 19 May 2014 12:55:53 +1000 [thread overview]
Message-ID: <20140519025553.GB8554@dastard> (raw)
In-Reply-To: <y2a4n0o1xt7.fsf@cartman.at.offog.org>
On Sat, May 17, 2014 at 11:53:08AM +0100, Adam Sampson wrote:
> Dave Chinner <david@fromorbit.com> 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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-05-19 2:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 5:56 [ANNOUNCE] xfsprogs: v3.2.0 released! Dave Chinner
2014-05-16 23:02 ` Adam Sampson
2014-05-17 0:23 ` Dave Chinner
2014-05-17 1:01 ` Eric Sandeen
2014-05-17 10:53 ` Adam Sampson
2014-05-19 2:55 ` Dave Chinner [this message]
2014-05-20 8:27 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140519025553.GB8554@dastard \
--to=david@fromorbit.com \
--cc=ats@offog.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox