Memory Leak problems with krb5_get_init_creds_password?

[Tom Yu]

>>>>> "brian" == brian joh <brian.joh at comcast.net> writes:

brian> How many known memory leaks still exist in MIT Kerberos?

You can look at our bug database at http://krbdev.mit.edu/rt/ for the
current status of reported bugs.  I don't think there are many at this
point.  We try to fix any leaks we discover or which are reported.  If
you know of any memory leaks which we have not fixed, please file a
bug report.  We can't fix leaks we don't know about.

brian> Also, this is not meant to be offensive, but if there are
brian> known memory leaks, why haven't they at least been minimized?
brian> I mean there are often easy workarounds.

With our current resources, we cannot possibly keep track of all the
operating system bugs which may introduce memory leaks.  Working
around every OS bug which causes a leak could rapidly cause
maintainability problems for us.

brian> If Chet read the source code properly, res_ninit() is being
brian> called before every DNS lookup, but given the leaks, it
brian> probably should be called from krb5_init_context().

The leak in res_ninit() results because the OS vendor did not expose
the corresponding res_ndestroy() API which is needed to free resources
allocated by res_ninit().  We consider this to be an OS bug.  While we
can work around OS bugs, we prefer that the OS vendor actually fix the
bug.

brian> (However, Chet's program doesn't actually test that this isn't
brian> already being done, since the krb5_init_context call is made
brian> inside of the while loop.)  The leak also could be minimized by
brian> checking timestamps and only calling res_ninit only if the DNS
brian> config files changed.

Another possible approach is to use res_search() rather than
res_nsearch() on platforms which lack res_ndestroy(), under the
assumption that the OS vendor has made the "static" resolver
interfaces thread-safe.  We could also cache the resolver state on a
per-thread basis, but that requires more work.

brian> But we can't do this until all leaks are at least minimized.
brian> I'd do it myself, but my company tries to avoid certain
brian> customizations.  Basically I can't modify/recompile the MIT
brian> source which BTW has created alot more work for me.  I could
brian> possibly submit a patch though.

If you find memory leaks which haven't been fixed yet, please file
bug reports on them so that we can be aware of them.  Good quality
patches are welcome.

---Tom