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

[John Zavgren]

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.Samersoff at oracle.com
To: john.zavgren at oracle.com
Cc: security-dev at 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.zavgren at oracle.com
> 


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...