bug-gnu-chess
[Top][All Lists]
Advanced

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

Re: Memory leak in Chess 5.00, 5.03 related to InitHashTable()


From: Lukas Geyer
Subject: Re: Memory leak in Chess 5.00, 5.03 related to InitHashTable()
Date: 14 Mar 2002 17:51:16 +0100

address@hidden (Simon Waters) writes:

> Sven Coenye wrote:
> > 
> > I would like to report a memory leak in GNU Chess 5.03 and below.
> > 
> > The InitHashTable function in file init.c can be called at will through
> > the 'hashsize' command. However, InitHashTable() fails to free the two
> > blocks of memory that were allocated for the pawn tables on the previous
> > call. I have been able to verify this with memwatch and its logs report
> > that 12288 bytes of memory are lost with each invocation of
> > InitHashTable() (using an unmodified common.h).
> 
> Excuse my ignorance of C.
> 
> Is there any reason not to use realloc here rather than the
> change suggested.
> 
> I think book.c could have done the same thing, and lose a static
> variable.

There are two (little) problems with realloc(): If you use realloc()
and then memset(), the realloc() does useless work if it has to move
the pointer to some other region. (It copies the contents to the new
region.)  Furthermore, conceptually there are some times, when the
memory is not allocated at all, at least in the book code. (Well, one
can of course do realloc(p,0).) 

Regarding the static variable: I introduced the it mainly as some kind
of safety belt, but we could as well get along without it. E.g., one
could make sure that every time that memory is freed, the pointer gets
set to NULL, so you always know whether memory is allocated just by
looking at the pointer. We then also initialize the pointer to be
NULL, so we can safely free() it, because free(NULL) should be a NOP,
even if I do not have the authoritative standard around. 

Actually, looking again at the code, the free()'s in InitHashTab() are
ok, because HashTab[k] for k=0,1 are static variables, thus
initialized to be 0. Leaves the memory leak for the pawn hash table as 
a bug.

> Noted that cmd.c has gained an unmatched memory allocation in
> inputstr, but the readline stuff defeats my understanding at the
> moment.

Well, readline() allocates memory for the string, which then has to be 
freed by the programmer.

Lukas



reply via email to

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