More memory leaks (1.6.4-beta1 release)
Marcus Watts
mdw at umich.edu
Wed Nov 11 12:00:17 EST 2009
> Date: Wed, 11 Nov 2009 13:57:01 GMT
> To: krbdev at mit.edu
> From: Dan Searle <dan.searle at censornet.com>
> Subject: More memory leaks (1.6.4-beta1 release)
>
> Hi,
>
> I've been debugging the squid_kerb_auth helper some more and have found
> yet more memory leaks. I missed these last round because I didn't take
> into account (ignored) the still reachable blocks (malloced blocks which
> still have valid pointers).
>
> I've ignores the instances (loss records) with just 1 block or what seem
> to be a "fixed" number of still reachable blocks, i.e. I've only
> included here the loss records which seem to scale with the number of
> iterations the authentication helper goes through, and so are a threat
> to a running process...
>
> ==5314== 372 bytes in 31 blocks are still reachable in loss record 76 of 82
> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314== by 0x4032BE5: gssint_g_set_entry_add (util_set.c:61)
> ==5314== by 0x4033B1B: g_save (util_validate.c:114)
> ==5314== by 0x404097A: krb5_gss_acquire_cred (acquire_cred.c:645)
> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
> (accept_sec_context.c:302)
> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>
> ==5314== 372 bytes in 31 blocks are still reachable in loss record 77 of 82
> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314== by 0x40A006A: krb5_ktfile_resolve (kt_file.c:207)
> ==5314== by 0x409D900: krb5_kt_resolve (ktbase.c:129)
> ==5314== by 0x409DB38: krb5_kt_default (ktdefault.c:41)
> ==5314== by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
> (accept_sec_context.c:302)
> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>
> ==5314== 527 bytes in 31 blocks are still reachable in loss record 78 of 82
> ==5314== at 0x4021BDE: calloc (vg_replace_malloc.c:397)
> ==5314== by 0x40A013A: krb5_ktfile_resolve (kt_file.c:223)
> ==5314== by 0x409D900: krb5_kt_resolve (ktbase.c:129)
> ==5314== by 0x409DB38: krb5_kt_default (ktdefault.c:41)
> ==5314== by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
> (accept_sec_context.c:302)
> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>
> ==5314== 2,852 bytes in 31 blocks are still reachable in loss record 81
> of 82
> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314== by 0x403F3C4: krb5_gss_acquire_cred (acquire_cred.c:497)
> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
> (accept_sec_context.c:302)
> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>
> ==5314== 256,308 bytes in 31 blocks are still reachable in loss record
> 82 of 82
> ==5314== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==5314== by 0x40A008A: krb5_ktfile_resolve (kt_file.c:211)
> ==5314== by 0x409D900: krb5_kt_resolve (ktbase.c:129)
> ==5314== by 0x409DB38: krb5_kt_default (ktdefault.c:41)
> ==5314== by 0x4041EC1: krb5_gss_acquire_cred (acquire_cred.c:171)
> ==5314== by 0x403D23F: krb5_gss_accept_sec_context
> (accept_sec_context.c:302)
> ==5314== by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x40510A7: spnego_gss_accept_sec_context (spnego_mech.c:1113)
> ==5314== by 0x4034178: gss_accept_sec_context
> (g_accept_sec_context.c:196)
> ==5314== by 0x8049C91: main (squid_kerb_auth.c:515)
>
> I've also debugged the squid_kerb_auth helper code and made sure it
> matches calls to gss_accept_sec_context() with calls to
> gss_delete_sec_context() which it does. So these still reachable leaks
> do appear to be bugs in the MIT Kerberos libs.
>
> Can anyone shed any light on these? as they are making MIT Kerberos
> unusable. Regards, Dan...
>
> --
> Dan Searle
>
> CensorNet Ltd - professional & affordable Web & E-mail filtering
> email: dan.searle at censornet.com web: www.censornet.com
> tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
> snail: Vallon House, Vantage Court Office Park, Winterbourne,
> Bristol, BS16 1GW, UK.
>
> CensorNet Ltd is a registered company in England & Wales No. 05518629
> VAT registration number 901-2048-78
> Any views expressed in this email communication are those of the
> individual sender, except where the sender specifically states them to
> be the views of a member of Censornet Ltd. Censornet Ltd. does not
> represent, warrant or guarantee that the integrity of this
> communication has been maintained nor that the communication is free
> of errors or interference.
>
>
> -------------------------------------------------------------------------------
> -----
> Scanned for viruses, spam and offensive content by CensorNet MailSafe
>
> Try CensorNet free for 14 days. Provide Internet access on your terms.
> Visit www.censornet.com for more information.
>
> _______________________________________________
> krbdev mailing list krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
Presumably your iteration count in this sample was 31.
3 of your 5 loss records are associated with calls to
krb5_ktfile_resolve. Calls to krb5_ktfile_resolve/krb5_kt_default
should be balanced with calls to krb5_ktfile_close.
The relevant logic is in krb5/src/lib/gssapi/krb5/acquire_cred.c
so that's presumably where the missing krb5_ktfile_close call ought
to be.
Both your remaining loss records are directly from gssapi.
specifically krb5_gss_acquire_cred. It looks like calls to that
should be paired up with calls to krb5_gss_release_cred.
That could happen at the end of krb5_gss_accept_sec_context
if verifier_cred_handle is passed as 0, otherwise, it looks like
the application (squid?) should be responsible. Presumably the
squid code should actually be calling gss_release_cred.
It's possible there's a bug here in the MIT code, but it would be
useful to first establish the credential isn't in fact being
passed out to squid.
-Marcus Watts
More information about the krbdev
mailing list