On 10/23/2012 10:03 AM, Dmitry Samersoff wrote:
John,
Good work! Thank you for doing it.
Yes John, thanks for the extra effort, this is much cleaner ( and as you
say also fixes the leak ).
-Chris.
Looks good for me!
-Dmitry
On 2012-10-23 12:56, John Zavgren wrote:
Greetings:
I've modified the procedure "Java_com_sun_security_auth_module_UnixSystem_getUnixInfo" so
that all four GetFieldID calls must be successful before it attempts to call "Set"
methods. This new program logic ensures that this procedure returns successfully if and only if all
the information about a user can be successfully retrieved. And, of course, the memory leak is
fixed also.
The new webrev is: http://cr.openjdk.java.net/~khazra/john/8000204/webrev.01/
Thanks!
John Zavgren
----- Original Message -----
From: dmitry.samers...@oracle.com
To: john.zavg...@oracle.com
Cc: security-dev@openjdk.java.net
Sent: Monday, October 22, 2012 4:53:56 AM GMT -05:00 US/Canada Eastern
Subject: Re: Memory leak fix for:
src/solaris/native/com/sun/security/auth/module/Unix.c
John,
Sorry for being later. Again, it's not to your changes but as well as
you are touching this code.
88, 103, 118: Type-o - we are checking for uid,gid,groups field,
but exception says "invalid field: username" in all cases.
It's better to fix it as well.
??: Does it make sense to abort after (*env)->ThrowNew(...) ?
-Dmitry
On 2012-10-20 00:28, 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));id
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
