On 12/13/12 6:37 AM, Andriy Gapon wrote:
on 12/12/2012 19:06 Adrian Chadd said the following:
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.
I have a quite different view on purpose and costs of KASSERTs.
Specifically referring to r243980 I do not think that "non-fatal asserts" should
really exist (or do exist). I wish all this muddying of KASSERT meaning
would get reverted.
These quite sensitive changes were rushed in, IMO.
having worked in a place where asserts were by default NON fatal, I can
say that it is a REALLY BAD IDEA.
it never did anything but cost us time and effort..
one reason it was there was the lack of a debugger in Linux at the time
but all ports had top pay the price... (new linux does have one at last)
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"
