Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c

[Bradford Wetmore]

Yes, that's what I meant.  Just that none of the other functions alloc'd 
memory internally that you had to manually free.

Thanks for checking.

Brad


On 10/19/2012 5:54 PM, John Zavgren wrote:
> Brad:
> I'm not sure that I completely understand your question, because this is C code and there are no objects involved. Nevertheless, I read through the procedures that are defined in this particular file (Unix.c) and balanced their memory allocations (malloc(), calloc()) against their memory deallocations (free()) and they seem to balance out now.
>
> John
>
> ----- Original Message -----
> From: bradford.wetmore at oracle.com
> To: john.zavgren at oracle.com
> Cc: security-dev at openjdk.java.net
> Sent: Friday, October 19, 2012 8:11:03 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Memory leak fix for: src/solaris/native/com/sun/security/auth/module/Unix.c
>
> Looks good, taken in isolation.
>
> Just to be sure, are there any other methods that might return some
> object that has to be freed.
>
> Brad
>
>
> On 10/19/2012 1:28 PM, John Zavgren wrote:
>> Greetings:
>> The following webrev image contains a fix for a memory leak that occurs in the procedure: Java_com_sun_security_auth_module_UnixSystem_getUnixInfo (JNIEnv *env, jobject obj) in the file: jdk/src/solaris/native/com/sun/security/auth/module/Unix.c
>>
>> http://cr.openjdk.java.net/~khazra/john/8000204/webrev/
>>
>> The leaked memory is associated with the pointer named "groups": gid_t *groups = (gid_t *)calloc(numSuppGroups, sizeof(gid_t));
>>
>> The procedure in question exits in many places and in every case it's necessary to deallocate this memory. The leak occurred because returns were being made without freeing it. I fixed the leak by modifying the code so that there is a common "exit point", that is reached from these same places via goto statements, that performs this common function, immediately before the "return" statement.
>>
>> Thanks!
>> John Zavgren
>> john.zavgren at oracle.com
>>