On 12/14/12 4:12 PM, Robert Watson wrote:
On Fri, 14 Dec 2012, John Baldwin wrote:
On Thursday, December 13, 2012 4:02:15 am Gleb Smirnoff wrote:
On Wed, Dec 12, 2012 at 04:53:48PM -0800, Alfred Perlstein wrote: A>
The problem again is that not all the KASSERTS are inviolable, if
you A> want to do a project to split them, then please do, it would
really be A> helpful, as for now, they are a mis-mash of
death/warnings and there are A> at least three vendors who approve
of this as well as 3 long term A> committers that approved my change
(not including Adrian).
Can you show examples of not inviolable KASSERTs?
There are none. They are all assertions for a reason. However, in
my experience at several large consumers of FreeBSD, no one wants to
run with INVARIANTS in production. Not because we don't want panics
(believe me, Yahoo! gets plenty of panics even with INVARIANTS
disabled), but because the performance overhead, and redefining
INVARIANTS into printf doesn't address that at all.
In the past, FYI, the two major INVARIANTS hits were un-inlining of
locking, and UMA using additional global locking to perform
heavier-weight sanity checking. For me, at least, the former wasn't
such a problem, but the latter was extremely measurable. I have
occasionally wondered if we should have another option name for
heavier-duty sanity checking, as is the case with WITNESS,
SOCKBUF_DEBUG, etc, so that INVARIANTS overhead can be made tolerable
for more real-world installations. As you observe, our invariants
tests are generally things where you catch critical problems in much
more debuggable states, rather than sources of additional fragility,
and it would be great if we could leave more in so that bug reports
were able to contain more information.
Robert
Yes.
The KTR system offers an interesting reference for a model that allows
us to make a compile time decision about which areas to trace.
There used to be a DIAGNOSTIC option for the more heavy checks, this is
either removed or just not used these days. Again, using a mask like
KTR might be a win if we bring back the equivalent of heavy weight
DIAGNOSTIC option.
Often I've been guilty of putting KASSERT(ptr != NULL) checks into the
code too. Those are really just to make it less painful when hitting
that bug, so instead of having to do a lot of homework to figure out the
fault address and line number, I can just get a pretty printed message
under INVARIANTS. Maybe those "pretty null checks" need to go under
another option, perhaps DIAGNOSTIC, or another .. ??PRETTY_PANIC.
Anyhow, I've always been a huge fan of FreeBSD due the additional
debugging checks it offered. I was the one that suggested splassert()
back in the day when we would continually find issues with spl calls.
Additionally I found doing filesystem work a ton easier with
DEBUG_VFS_LOCKS under FreeBSD than under Darwin which at the time did
not have such a feature.
One of my great joys in developing FreeBSD is the flexibility and power
it offers us as developers by giving us a huge library of debugging tools.
-Alfred
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
