On Tue, Apr 24, 2007 at 01:12:26PM +0200, Alan DeKok wrote:
Kostas Zorbadelos wrote:
I disagree with you on this one Alan. I discovered all these issues I mention the hard way, after our radius server stopped running in random times (after a failure in rad_assert() in request_list.c around the section ... In production environments the server should be able to at least report the errors it encounters and continue operations. Service availability is the most important.
My point was that it should continue doing *what*? The assertions are there to catch catastrophic failures in the code. If the assertion trips, it's doing so because the error is non-recoverable.
If you disable the assertions, the server may look like it's still running. But there's no guarantee that it will do anything useful. It may crash randomly later, for reasons that are difficult to track down. The only *safe* thing to do is to revert to a known working state. i.e. restart from scratch.
In the code snippet I sent, from what I can tell, nothing catastrophic happens. The code checks to see if it is time to send a delayed reject back to the client and asserts that there is no child thread that works on that request. Anyway, if the developer flags are switched off rad_assert() does nothing. This is the way it is defined: #ifdef NDEBUG #define rad_assert(expr) ((void) (0)) #else #define rad_assert(expr) \ ((void) ((expr) ? 0 : \ rad_assert_fail (__FILE__, __LINE__))) #endif So if someone compiles freeradius without developer flags he actually de-activates all assertions :)
As far as I can tell, the following minor patch should take care of the issue of having developer flags switched off be default:
OK, thanks.
There is the Solaris issue however. I will try to track it down and send a patch for this too if I can. Kostas Zorbadelos
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog -