On Mon, May 19, 2014 at 12:55:53PM +1000, Dave Chinner wrote: > 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... And it's not straight forward, either, because some of the ASSERT()s have code in them that is only present when the libxfs code is built with -DDEBUG, so compiling in the asserts without enabling -DDEBUG is not going to work. And, well, compiling with -DDEBUG itself deosn't work nor with -DNDEBUG -DDEBUG because -DDEBUG enables code that has unhandled kernelisms in it. So, right now, don't remove -NDEBUG from the libxfs/Makefile. It's there for a good reason right now. i.e. removing it requires some non-trivial work, and even if we do make it compile the resultant code will probably not work (i.e. assert fail unnecessarily) given the requirements that userspace has for tolerance of inconsistent on-disk states. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
