On 21/05/13 09:44, Nathan Scott wrote:
... Looking forward to that logcheck discussion,
I'm guessing/hoping that since thats using raw, non-interpolated mode
it will be able to detect this class of time-warp problem.
Yes. Hopefully the logcheck RFC will be in another mail later today.
...
It already needs libpcp_fault, so most people will continue to
see this test as Not Run.
Should we start building this variant with each build instead of as
a separate build? Perhaps with some old-school makefile magic of the
libpcp/{src,o32,n32,64} ilk, so that there is a libpcp/fault with the
special compilation option used?
I don't think so. The coverage here is pretty spotty and driven by my
earlier attempts at systematic code coverage analysis that were never
completed (only 5 of 60 source files in libpcp have fault injection
points added) and some issues with lock nesting that are long-gone ... I
think running the qa tests (that depend on this library) _somewhere_ has
some merit, but running it in lots of places is probably no a big win.
Also worth a read for future thinking about fault injection:
http://sourceware.org/glibc/wiki/Testing/WhiteBox
Perhaps we can tackle fault injection in a less invasive manner (using
the regular library builds) with systemtap and/or dyninst someday.
I can see the merit in this approach for the engineer validating a
hypothesis or code change. I would be interested to hear if anyone has
experience (leading question!) using this approach for systemic QA and
regression testing of released code.
For libpcp_fault, almost none (2 of 17) of the fault injection points
are at the entry point to a routine, so we'd be relying on source line
numbers to align the fault point with the logic of the source code ...
this seems rather fragile to me.
But all good fodder for discussion ...
|