File and line numbers in error messages
raeburn at MIT.EDU
Tue Apr 28 16:14:55 EDT 2009
On Apr 28, 2009, at 15:37, ghudson at MIT.EDU wrote:
> We had a request from within the MIT krb5 team to optionally include
> file and line numbers in error messages.
> This is fairly easy to do
> with a macro like (relies on a gcc-ism):
> #define krb5_set_error_message(ctx, code, fmt, ...) \
> krb5_set_error_message_fl(ctx, code, __FILE__, __LINE__, fmt, ##
Even without the gcc bits, if you have C99 support it's doable. I
don't know what you'd do for Windows though, where we're stuck with
VS2003. I guess you could have it permanently disabled there, along
with pre-C99 non-GCC platforms.
> kinit: get_in_tkt.c: 1503: Client 'blah at ATHENA.MIT.EDU' not found in
> Kerberos database while getting initial credentials
It's nitpicky, but I think I'd rather see "(get_in_tkt.c:1503)" added
at the end.
> We don't want this enabled in production builds; it's not the kind of
> error message you want end users to see on a day-to-day basis and it
> adds a lot of static strings to the library object files. So we need
> some kind of compile-time flag, either specified through a make-time
> option ("make CPPFLAGS=-DBLAH") or a configure-time option
> ("./configure --enable-blah").
I'd think for many UNIX builds you'd actually want the capability
compiled in, but turned off by default. Then when someone reports
"Waah, my program reports 'generic Kerberos error' using the Kerberos
packaged with OpenDebHatBuntuKnopp 4.7, what's it mean?" and we don't
know, we can say, "set KRB5_HELP_ME_OBI_WAN_KENOBI=1 and run it again"
and get some useful information out without the user having to
But the krb5_set_error_message calls don't happen in enough places.
Not only do some places still need updating to call it, but many
places in the code may have nothing else interesting to report, or
don't even have a context in which to store the information. It might
be helpful to have a simple function that can be called within the
library to indicate, "hey, I'm generating error code X here", where
one could set a breakpoint and/or cause it to print the file and line
number when debugging, and which would do nothing normally. E.g.,
change "return KRB5_ERR_FOO" to "return mkerr(KRB5_ERR_FOO)" with
"#define mkerr(CODE) krb5int_mkerr(CODE,__FILE__,__LINE__)" etc; code
size may suffer a little, but speed isn't very important in the error
> I'm also aware that this feature isn't very useful if no one is really
> aware of it, as seems true of a lot of our debugging features. I'll
> probably create a "debugging tips" page in our wiki to help advertise
> features like this.
Having written more than one bit of debugging code that's fallen into
this category, I agree, this is a good idea....
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium
More information about the krbdev