RFR 8000203: file descriptor leak, src/solaris/native/java/net/net_util_md.c ... AND a potential realloc()-related memory leak.

Kurchi Hazra kurchi.subhra.hazra at oracle.com
Wed Oct 24 10:48:39 PDT 2012


Sounds good, thanks a lot.

- Kurchi


On 24.10.2012 10:47, John Zavgren wrote:
> That's right Kurchi. If realloc were to fail, in the original code, then the pointer: loRoutes would be set to the value zero, but the memory that this variable previously pointed to would still be allocated. So, basically, if realloc failed, then we'd leak memory.
>
> John
> ----- Original Message -----
> From: kurchi.subhra.hazra at oracle.com
> To: john.zavgren at oracle.com
> Cc: net-dev at openjdk.java.net
> Sent: Wednesday, October 24, 2012 1:31:36 PM GMT -05:00 US/Canada Eastern
> Subject: Re: RFR 8000203: file descriptor leak, src/solaris/native/java/net/net_util_md.c ... AND a potential realloc()-related memory leak.
>
> Just for the sake of understanding the fix better, loRoutesTemp will
> point to 0 if the realloc() request fails,
> and we still need a reference to the older allocated memory (loRoutes in
> this case) in order to free it. Hence
> the need for a temporary variable here?
>
> - Kurchi
>
>
> On 24.10.2012 06:27, Chris Hegarty wrote:
>> Looks good to me. Thanks for going the extra mile here.
>>
>> -Chris.
>>
>> On 24/10/2012 14:16, John Zavgren wrote:
>>> Greetings:
>>>
>>> I'm requesting a review of a software change that fixes a file
>>> descriptor leak AND a potential memory leak that involves memory
>>> reallocation (realloc()). The webrev image is in the following location:
>>>
>>> http://cr.openjdk.java.net/~chegar/8000203/webrev.01/
>>>
>>> Thanks!
>>> John Zavgren
>>> john.zavgren at oracle.com

-- 
-Kurchi




More information about the net-dev mailing list