[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hash table memory leak

From: J. Grant
Subject: Re: hash table memory leak
Date: Thu, 11 Mar 2004 22:01:12 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030824

on the 11/03/04 06:50, Paul D. Smith wrote:
%% "J. Grant" <address@hidden> writes:

  jg> I noticed the global hash tables leak memory as they are not freed
  jg> before make exits.

There's no need to free things before a process exits: when a process
exits the operating system frees up all the heap that was allocated.

These leaks may not be recovered by the OS.  It also makes sense to free
ones own memory so that the other memory leaks can be located and fixed.
Presently 149,627 bytes goes amiss without even loading a makefile, this
breaks down into:

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

I have all the callstacks at allocation and can create a patch to correct
these if agreed.

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

Doing this just causes the process to take longer to shut down, doing
nothing useful.

To tidy up would take a minute fraction of a second.  Completely
unnoticeable to any user of make (if the reason there is no hash table
tidy (and other allocated memory) is because of perceived speed loss).
(I encountered these hash table leaks when running make with no
arguments, which finishes basically as soon as I have pressed "Enter".

Doesn't Windows do this for you as well?

I do not think it achieves this perfectly, often reboots are required to
recover lost memory.  I expect other OS may not recover this lost memory
in an executable.  It also makes finding other memory leaks very
difficult when there are thousands of individual hash leaks like this...

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

Kind regards


reply via email to

[Prev in Thread] Current Thread [Next in Thread]