Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Dec 2012 09:06:22 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, src-committers@freebsd.org
Subject:   Re: svn commit: r244112 - head/sys/kern
Message-ID:  <CAJ-Vmo=U04GX%2BZyKuzXLwV%2BPpzU6_dm5BCmL=DWfsmhTVAR%2BsA@mail.gmail.com>
In-Reply-To: <201212121046.43706.jhb@freebsd.org>
References:  <201212110708.qBB78EWx025288@svn.freebsd.org> <201212121046.43706.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=U04GX%2BZyKuzXLwV%2BPpzU6_dm5BCmL=DWfsmhTVAR%2BsA>