RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks

[Chris Hegarty]

On Wed, 17 Feb 2021 10:30:45 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> In another bug  this question from me  was answered by  Alan Bateman :
>> 
>> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I started to wonder what happens to the allocated memory in the same file in handleSendFailed ( if ((addressP = malloc(dataLength)) == NULL) ) in early return cases incl. the CHECK_NULL , is there some deallocation missing there too ?
>> 
>> 
>> Yes, the error paths in handleSendFailed should be looked at. If NewDirectByteBuffer or recvmsg fails then addressP needs to be freed. Furthermore, if the NewObject fails and bufferObj != NULL then the memory for the direct buffer will need to be freed too (as JNI NewDirectByteBuffer does not setup a cleaner).
>> 
>> 
>> So I added freeing of the malloced memory to handleSendFailed .
>> Please review !
>> 
>> Thanks, Matthias
>
> Marked as reviewed by chegar (Reviewer).

This changes look good to me.  Additionally, and separately, I have filed JDK-8261881.

>From 8261881 : The SCTP implementation uses NewDirectByteBuffer to create a new direct byte-buffer in native code. Such creations of a direct byte-buffer are not automatically associated with a Cleaner, therefore the native memory associated with the buffer may not be released when the buffer is no longer reachable. 

The Java code that results in the native NewDirectByteBuffer should be examined with a view to creating a cleaner and assigning it to the direct byte-buffer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2586