Thank you, Valerie! On Thu, Apr 28, 2016 at 9:58 PM, Valerie Peng <valerie.p...@oracle.com> wrote:
> > Interesting... That's a very good catch. > The webrev looks fine to me. > Valerie > > > > On 4/28/2016 5:40 AM, Thomas Stüfe wrote: > > Hi all, > > could you please review this small fix? > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155211 > > Basically, during benchmarks our Solaris VMs went out-of-native-memory; > when we investigated, we saw ~31million small lost allocations from > nativeCrypto.c:663. Looking at the source shows that the output buffer is > not deallocated if outLen is 0. > > outLen can be 0 if the java output buffer was len 0 to begin with, or if > the outOfs equals output array len, or if CipherFinal returns 0. In the > first two cases we will call calloc(0), which on Solaris is implemented as > a real calloc (returns a unique pointer which needs to be freed). > > I changed the coding to always free the internal buffers. I also removed > the (bufOut != NULL) condition from SetByteArrayRegion, because that should > be always true at this point. > > Kind Regards, Thomas > >
