krb5_init_context krb5_parse_name memory leaks

[Ken Raeburn]

(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