Re: hash table memory leak

[Paul D. Smith]

%% "J. Grant" <address@hidden> writes:

  jg> It also makes sense to free ones own memory so that the other
  jg> memory leaks can be located and fixed.

You have to be careful about what you mean by "memory leaks".  A memory
leak is some memory which has been allocated on the heap, but the
pointer to it has been lost (there is no userspace code which can find
that memory, so it can never be freed by the user).

Memory which is pointed to by some userspace code, so that it _could_ be
freed, but just happens to not be freed before the process exits, is not
a memory leak.

  jg> Presently 149,627 bytes goes amiss without even loading a
  jg> makefile, this breaks down into:

  jg> 1) 15 hash_init leaks, 16,128 bytes.
  jg> 2) 3 hash_rehash leaks, 17,408 bytes.
  jg> 3) 225 define_variable_in_set (xstrdup) leaks, 4895 bytes.
  jg> 4) 9,591 define_variable_in_set and other functions (xmalloc) leaks,
  jg>     104,490 bytes.
  jg> 5) 1 opendir (malloc) leak, 528 bytes.
  jg> 6) 1 FILE_TIMESTAMP leak 12bytes.  (as fixed in my previous email)

If you mean that this memory is just not freed when make calls exit(),
then that's fine (with me).  Make has never been written to attempt to
free this memory.

But these are _not_ leaks.

  jg> Many OS have poor memory management, Microsoft win9x is one OS
  jg> which often looses memory allocated to processes which do not
  jg> release before terminating.  I am sure there are many other OS
  jg> which will not recover the memory.

Not really.  GNU make only supports DOS/Windows, OS/2, Amiga, UNIX-ish,
and VMS.  Of those, I know for a fact that all the UNIX and VMS systems
behave properly, and I'm quite sure Amiga and OS/2 do as well.  And, as
much as I like to abuse them the newer Windows versions almost certainly
work properly here.  DOS and Windows 9x might not be so pleasant I
suppose.

  jg> I do not think it achieves this perfectly, often reboots are
  jg> required to recover lost memory.

Very sad.

  jg> I expect other OS may not recover this lost memory in an
  jg> executable.

I've yet to meet one...

  jg> It also makes finding other memory leaks very difficult when there
  jg> are thousands of individual hash leaks like this...

They're not leaks!! :).

Anyway, you just need better tools :).  There are a number of heap
analyzers for UNIX systems, for example, that can distinguish between
memory that has really been lost, and memory which just hasn't been
freed yet.  I use one of these (valgrind) fairly regularly on GNU
make.  I've also used Purify (and there used to be other people who
would do Purify runs as well).

  jg> Would you reconsider and support a hash table tidy function
  jg> addition please?

Send it and if it's not too gross I'll add it.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist