Reachable memory left behind by simple kadmin client?

[Greg Hudson]

On 12/22/2011 02:22 AM, Russ Allbery wrote:
> When I run a very simple kadmin client program, which sets the password
> expiration for a principal using a keytab to authenticate, valgrind
> reports some 19KB of memory that's "still reachable" at the exit of the
> program.  This is despite the fact that my program has no static variables
> and frees all of its own memory.  The report says that most of this memory
> is either allocated from the profile library or inside GSS-API.

Most of the records suggest a krb5 context which wasn't freed and is
still reachable from somewhere.  I don't really know where this would
be.  As far as I can tell, neither libkadm5clnt, libgssrpc, nor
libgssapi keep a static krb5 context around (Heimdal does, in
thread-specific storage, but we don't currently do that).  All of the
stack traces stop at krb5_init_context for some reason, making it hard
to see where the still-reachable context was allocated.

Records 2 and 3 are an artifact of how com_err works.

Records 6-8 are an artifact of an API used to communicate the ccache
name between libkadm5 and gss-krb5, which uses thread-specific storage.

Records 12 and 21 are an artifact of the gssrpc library allocating
private storage blocks.  I think this memory could be lost if the gssrpc
library were loaded and unloaded repeatedly, so it's not a great
practice, but the library is based on very old code.