krb5_init_context krb5_parse_name memory leaks

[Stephen Ince]

Gotcha. Won't use reply=to. I did not know that. I will try and generate a 
simple test case.


----- Original Message ----- 
From: "Ken Raeburn" <raeburn at MIT.EDU>
To: "Stephen Ince" <since at opendemand.com>
Cc: <krbdev at MIT.EDU>
Sent: Friday, November 14, 2008 1:32 PM
Subject: Re: krb5_init_context krb5_parse_name memory leaks


> (As an aside, please don't use "reply-to" to select a mailing list for  a 
> message that isn't related to the message you're "replying" to.  The 
> message comes out with headers that say it's following up to that  message 
> and belongs in the same thread.  I suspect a lot of people use  threaded 
> views in their mail readers.  If I hadn't been interested in  following up 
> on "AEAD Encryption API" email when reading email just  now, I would've 
> skipped right over the whole "thread" including your  message, which 
> would've been displayed as one line in my mailbox  summary.  Similarly, if 
> I wanted to reply to some of the AEAD  discussion just now, I would have 
> examined the thread's messages, and  still skipped yours as off-topic.)
>
> On Nov 14, 2008, at 11:04, Stephen Ince wrote:
>> I do not know if I should post this question here or the general.
>> I noticed that I have the kfw-3-2-2-final kerberos api has some memory
>> leaks. I am running some purify memory profiling tests. Here is what I
>> noticed.
>>
>>    // memory leak for krb5_parse_name (allocate)
>>    if (err = krb5_parse_name(krb5->context, username, &krb5->client)){
>>
>>   //deallocate
>>   if (krb5->client) krb5_free_principal(krb5->context, krb5->client);
>>
>> [W] MLK: Memory leak of 28 bytes from 1 block allocated in 
>> krb5_parse_name
>> [KRB5_32.DLL]
>>        Distribution of leaked blocks
>>                28 bytes from 1 block of 28 bytes (0x003c8af8)
>>        Allocation location
>>            malloc         [C:\WINDOWS\SYSTEM32\MSVCR71.DLL]
>>            krb5_parse_name [C:\OPENLOAD\BIN\KRB5_32.DLL]
>
>
> On a 32-bit platform, 28 bytes looks like the right size for 
> krb5_principal_data.  Maybe principal name components too, but you  don't 
> indicate what name is being parsed.  However,  krb5_free_principal does 
> free the principal data structure that it's  passed.
>
> These little fragments of sources aren't enough for me to figure out 
> what's going on (e.g., how do I know the free routines are being 
> called?), though I could write a test case of my own and see if maybe 
> purify complains about it on Solaris (which is the only platform where 
> we've got Purify), or valgrind on Linux/x86, but I can't be sure of 
> reproducing the problem you're seeing.  Can you give me a (simple?)  test 
> case that definitely shows the problem for you?
>
> Ken
>