Reachable memory left behind by simple kadmin client?

[Russ Allbery]

Greg Hudson <ghudson at MIT.EDU> writes:

> 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.

Yeah, that's what it looked like to me too, but I can't figure out where
it is.  It's possible that I have some other, subtle bug in my code, but I
can't figure it out if so.

> 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.

Yes.  This is probably because I'm using the system MIT Kerberos libraries
with the debugging packages, so they were built with optimization.  If I
rebuilt them without optimization and used LD_LIBRARY_PATH, I'd probably
get better traces.  I may try to do that if I get a chance later, although
I've already spent a lot of time chasing memory pseudo-leaks (in all sorts
of different code) and am getting kind of bored of it.  :)

If anyone is interested in taking a look, clone:

    git://git.eyrie.org/kerberos/pam-krb5.git

follow the test suite setup instructions in README and
tests/config/README, and run:

    ./autogen
    ./configure
    make CFLAGS=-g check-valgrind

and then look in tmp-valgrind/*.  This is still a work in progress and
more things will be moving around; for example, libkadm5clnt is currently
hard-coded in Makefile.am and will be replaced by an Autoconf probe.

> 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.

Thanks for this information!  I'll try to update the valgrind suppressions
for these, at least.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>