kassert()s are already optional. Ie, you can choose to not compile them in.
So the __dead2() code path bit for doing KASSERT() -> kassert_panic() at compile time isn't a problem. The problem is where you do panic() -> kassert_panic() (eg in the Witness code) which is what Alfred discovered shortly after doing up his initial patch. Anything which is a KASSERT() can and should be treated as a run-time warning just as much as a run-time "crash here so I can figure out what broke." Having the warning in a production box is going to be helpful for developers. Adrian On 12 December 2012 07:46, John Baldwin <j...@freebsd.org> wrote: > On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote: >> Author: alfred >> Date: Tue Dec 11 07:08:14 2012 >> New Revision: 244112 >> URL: http://svnweb.freebsd.org/changeset/base/244112 >> >> Log: >> Cleanup more of the kassert_panic. >> >> fix compile warnings on !amd64 and NULL derefs that would happen >> if kassert_panic() would return. > > This is one reason why having kassert not panic is such a bad idea. There are > tons of places where the compiler knows that panic() is __dead2, and there is > no cleanup code to handle what happens when an invariant is violated. This is > not safe to run in the field unless your customers do not care about their > data. If you are interested in doing regression tests, I am using a very > different approach for some locking regression tests I am working on in p4 > that allow you to use a wrapper around setjmp/longjmp to "catch" panics > somewhat like exception handling in C++/Java (though much cruder). However, > evne that is only intended for testing, not for production cases where > production data is at stake. > > -- > John Baldwin _______________________________________________ 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"
