Thanks Ivan! On Thu, Apr 28, 2016 at 10:51 PM, Ivan Gerasimov <ivan.gerasi...@oracle.com> wrote:
> Ah, please ignore my previous message, I read the code wrongly. > > Your fix looks good. > > With kind regards, > > Ivan > > On 28.04.2016 19:12, Ivan Gerasimov wrote: > > Hi Thomas! > > Wouldn't it make sense to declare > > unsigned char bufOut[1]; > > and avoid allocation/deallocation of this buffer altogether? > > > With kind regards, > > Ivan > > > On 28.04.2016 15:40, 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 > > > >
