Ticket History #2872: memory leak in dns code

I set up a series of realm R1.MIT.EDU .. R4.MIT.EDU with cross-realm
keys, got a ticket as principal x@R1, and ran "kvno
service2@R4.MIT.EDU" with the current 1.4 branch sources, under
valgrind on x86-linux. So intermediate TGTs were needed for R1->R2,
R2->R3,
R3->R4.

Aside from the leaks related in ticket 2541, this one showed up. Some
experimentation with different service principal realms and different
sets of existing tickets indicates that the number of leaked blocks
varies, presumably with the number of KDC requests.

==30513== 280 bytes in 10 blocks are definitely lost in loss record 7 of 7
==30513== at 0x1B903D38: malloc (vg_replace_malloc.c:131)
==30513== by 0x1B9D118B: __libc_res_nsend (in /lib/libresolv-2.3.2.so)
==30513== by 0x1B9CFE19: __libc_res_nquery (in /lib/libresolv-2.3.2.so)
==30513== by 0x1B9D056A: __libc_res_nquerydomain (in /lib/libresolv-2.3.2.so)
==30513== by 0x1B9D0131: __libc_res_nsearch (in /lib/libresolv-2.3.2.so)
==30513== by 0x1B9D0479: __res_nsearch (in /lib/libresolv-2.3.2.so)
==30513== by 0x1B9787EC: krb5int_dns_init (dnsglue.c:106)
==30513== by 0x1B978C34: krb5int_make_srv_query_realm (dnssrv.c:106)
==30513== by 0x1B97BAB1: krb5_locate_srv_dns_1 (locate_kdc.c:518)
==30513== by 0x1B97BC45: krb5int_locate_server (locate_kdc.c:595)

At first glance, I think it may be a glibc bug. There is a res_nclose
routine that we aren't calling, but I don't think it'll fix this.

Ken

pullup from trunk


To generate a diff of this commit:



cvs diff -r1.275 -r1.275.4.1 krb5/src/lib/gssapi/krb5/ChangeLog
cvs diff -r1.40 -r1.40.4.1 krb5/src/lib/gssapi/krb5/acquire_cred.c
cvs diff -r1.84 -r1.84.4.1
krb5/src/lib/gssapi/krb5/init_sec_context.c

[tlyu - Thu Jan 13 16:55:17 2005]:


previous commit should have gone to [2875]. copied there.

So we've got one leak in res_nsend() in Linux, and a different one in
res_ninit() in Solaris libresolv. res_ndestroy() in the BIND sources
looks like it does the right things with resources allocated by
res_ninit(), but neither Solaris nor Linux exports it. All of these are
reasonably considered OS bugs, so what we have now (call res_ndestroy()
if we can find it) is probably the best we'll get unless we do
thread-specific caching, or caching in krb5_context, or mutex around
calls to the non-thread-safe resolver APIs.

pullup from trunk


To generate a diff of this commit:



cvs diff -r5.479.4.4 -r5.479.4.5 krb5/src/ChangeLog
cvs diff -r1.308.4.1 -r1.308.4.2 krb5/src/aclocal.m4
cvs diff -r5.412.2.4 -r5.412.2.5 krb5/src/lib/krb5/os/ChangeLog
cvs diff -r5.3 -r5.3.2.1 krb5/src/lib/krb5/os/dnsglue.c