[160] in Hesiod

home help back first fref pref prev next nref lref last post

Re: Major memory leak in hes_resolv

daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Oct 8 19:12:58 1993

Date: Fri, 8 Oct 93 19:10:57 EDT
From: tytso@MIT.EDU (Theodore Ts'o)
To: mcb@mach.eng.hou.compaq.com
Cc: hesiod@MIT.EDU, kutcher@mach.eng.hou.compaq.com
In-Reply-To: Mike Busby's message of Fri, 8 Oct 93 16:38:44 CDT,

   From: mcb@mach.eng.hou.compaq.com (Mike Busby)
   Date: Fri, 8 Oct 93 16:38:44 CDT

   In the process of debugging a problem, Jeff found a memory leak in
   hes_resolv.  If succesive calls are made to this function, memory
   is not de-allocated.  He found this by running the Purify program
   on a program that iterated with hes_resolv in the loop.

It is the program's responsibility to free the data structures returned
by hes_resolve.  In this fashion, hes_resolve is more like strdup() in
that it returns a pointer to allocated memory, than gethostbyname()
which returns a pointer static memory.

So it's not a bug, but an issue of misunderstanding the programming
interface to hes_resolve().

It's actually a feature, since if a program nees to call hes_resolve
multiple times to get various different pieces of information, it
doesn't need to copy the returned information to a another variable
before calling hes_resolve() again.  Contrast this with the behavior of
gethostbyname(), where many a bug has been called by having a procedure
call gethostbyname(), and having it try to use the resulting information
both before and after calling another function which also happens to
call gethostbyname() for another purpose, unbeknownst to the author of
the first procedure....

						- Ted

home help back first fref pref prev next nref lref last post