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.wetm...@oracle.com
To: john.zavg...@oracle.com
Cc: security-dev@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.zavg...@oracle.com
