>>>>> "brian" == brian joh <[EMAIL PROTECTED]> 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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
