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.ha...@oracle.com
To: john.zavg...@oracle.com
Cc: net-dev@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.zavg...@oracle.com
--
-Kurchi
