<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Interesting... That's a very good catch.<br>
The webrev looks fine to me.<br>
Valerie<br>
<br>
<br>
On 4/28/2016 5:40 AM, Thomas Stüfe wrote:
<blockquote
cite="mid:CAA-vtUxeMmKmxjJiWuYJReKB2WbuxoH9g10=bFG46xokBLqU0g@mail.gmail.com"
type="cite">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>could you please review this small fix?</div>
<div><br>
</div>
<div>Webrev: <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Estuefe/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 moz-do-not-send="true"
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>
</blockquote>
</body>
</html>