<div dir="ltr">Hi all,<div><br></div><div>could you please review this small fix?</div><div><br></div><div>Webrev: <a href="http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/">http://cr.openjdk.java.net/~stuefe/webrevs/8155211-ucrypto-lib-mem-leak/webrev.00/webrev/</a></div><div><br></div><div>Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8155211">https://bugs.openjdk.java.net/browse/JDK-8155211</a></div><div><br></div><div>Basically, during benchmarks our Solaris VMs went out-of-native-memory; when we investigated, we saw ~31million small lost allocations from nativeCrypto.c:<span style="color:rgb(0,0,0)">663. Looking at the source shows that the output buffer is not deallocated if outLen is 0.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,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).</span><br></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">I changed the coding to always free the intern</span>al buffers. I also removed the (bufOut != NULL) condition from SetByteArrayRegion, because that should be always true at this point.<br><span style="color:rgb(0,0,0)"><br></span></div><div>Kind Regards, Thomas</div><div><br></div></div>