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
