More memory leaks (1.6.4-beta1 release)
Markus Moeller
huaraz at moeller.plus.com
Wed Nov 11 16:04:22 EST 2009
"Marcus Watts" <mdw at umich.edu> wrote in message
news:E1N8GYL-0005yn-Kd at bruson.ifs.umich.edu...
>> 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.
This is a standalone application. All interaction with squid is via stdin
(base64 encoded token) and stdout.
> 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.
>
I tested in the past several MIT/Heimdal versions on different Linux
distributions. Some distribution have fixed MIT memory leaks others haven't.
I think my squid_kerb_auth code is correct in freeing allocated memory (at
least i have seen one or two Linux distributions e.g. centos which don't
show leaks)
> -Marcus Watts
> _______________________________________________
> krbdev mailing list krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
Regards
Markus
More information about the krbdev
mailing list