Re: [ SEPOL ] Move more things to newer debug system

[Joshua Brindle <jbrindle@tresys.com>]

Stephen Smalley wrote:

>On Wed, 2005-09-14 at 10:45 -0400, Joshua Brindle wrote:
>  
>
>>What I mean is, if there are multiple calls to DEBUG prior to returning 
>>to the originating function then there are multiple error messages of 
>>varying specificity sitting around somewhere, assuming we even store 
>>them all and not just the last one. This isn't ideal for error 
>>reporting, but it is for debugging.
>>    
>>
>
>Even in the error reporting case, allowing for multiple messages (e.g.
>for multiple assertion failures, hierarchy failures, etc) is useful.
>Those would be of comparable specificity rather than varying degrees.
>
>  
>
yes, in those two special cases reporting multiple messages is useful, 
we may need to handle them seperately. There is nothing preventing 
multiple error messages with write_error, we could even add append_error 
and have multiple errors in the same buffer. Granted that, at least with 
assertion failures, the buffer wouldn't be large enough to hold all the 
errors.

>If omitting the traceback data is your primary concern, possibly it
>could be explicitly identified in some manner in the DEBUG() interface
>so that the callback can easily drop it for error reporting purposes.
>
>  
>
Omitting it isn't my concern if it is really for debugging, I do not 
think that we should try to use the debug system for error reporting to 
the originating function if it is going to be a debug system.

>> Personally, again, I feel that gdb 
>>is far superior to any kind of debug system you can put in a library so 
>>I'd rather focus on proper error reporting, which DEBUG doesn't do in a 
>>reasonable way.
>>    
>>
>
>Requiring people to re-run the offending code through a debugger
>significantly reduces your ability to get useful bug reports...
>
>  
>
Fair enough, I had only thought about the developer case, not the user 
case. It seems like the debug system is useful, especially in this case, 
for debugging, but not particularly for error reporting. If Ivan wants 
to put DEBUG in libsemanage we are ok with that, assuming that it is 
used for debugging and corresponding error reporting is also added for 
errors. Since the policy server will be a primary user of libsemanage, 
and is threaded we really need the error reporting in the connection 
handle to report to the user on the other end, but debugging can't hurt.

As for libsepol, I don't think we should go down this road of using 
DEBUG for error reporting. Since parts of libsepol aren't threadsafe 
already (eg., reading, writing) we can use a global error buffer for 
error reporting. If the need for thread safety ever comes up we could 
fix up the API at that point but, as you said before, libsepol is static 
with few users, so API changes aren't a dramatic thing.

In short, it is apparent that we need both debug and write_error, for 
different reasons, and I see no reason why we can't use both. DEBUG, 
then, could be used more liberally for general library information since 
it would presumably default to off.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.