RFR: JDK-8261601: free memory in early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0

[Alan Bateman]

On Sat, 13 Feb 2021 17:27:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There seems to be an early return in Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory.
>> 
>> Sonar reports :
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=false&severities=BLOCKER&types=BUG
>> 
>> Potential leak of memory pointed to by 'newBuf'
>> I adjusted  the early return and added freeing memory .
>> 
>> 
>> 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 ?
>
>> 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).

I see this has been integrated but the fix is incomplete. Are you planning to create a follow-on issue for the issues that I pointed out above?

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

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