> > After it built, it seems to work fine.
> 
> Seems to work, yes. Let it run for a while playing (with) itself, and
> without having looked at what the code does, I'd say that it has a
> a memory leak. I started it this morning and promply forgot about it
> since I was working on another machine. In just under 5 hours it has
> grown to:
> 
> USER       PID %CPU %MEM   VSZ  RSS TT  STAT STARTED       TIME COMMAND
> root     27359  9.3 76.6 31944 19880 p1  R+    8:19AM   76:42.62 ./gomoku -c
> 
> and it has only completed 34 of whatever it is doing. The machine is now
> busily swapping... Of course maybe that is what it is _supposed_ to do.
> I dunno (don't play games).

So, in less than 45 minutes (i dunno what the total real time was,
since i was doing other things and wasn't paying attention), it got
to:

games     1268  0.0 27.4 24488 24928 p2  IN+   8:39PM   17:29.03 gomoku -c -d 

on one of my boxes, and finished its game with itself.  (it won!)


That memory-sucking problem looks like it could be bad memory
fragmentation caused by the BSD malloc.

I added -lgnumalloc to its LDADD, and noticed that:
	(1) a game finished in < 15 minutes real time.  (It won
	    again!)

	(2) its memory usage was less, and stable over much of the
	    lifetime of the game.  ps said at various times (lines
	    trimmed to fit in 80 columns):

cgd     2491 99.0 13.3 11536 12072 p2  R+    9:38PM    3:35.59 obj/gomoku -c -
cgd     2491 98.8 13.3 11536 12072 p2  R+    9:38PM    9:12.22 obj/gomoku -c -
cgd     2491 93.4 13.3 11536 12072 p2  SN+   9:38PM   13:45.27 obj/gomoku -c -


It's not clear to me that there is a leak in gomoku, though if
somebody has access to a good memory profiling and leak-checking tool,
they're certainly free to look for leaks...


I would be tempted to add -lgnumalloc to gomoku's Makefile's LDADD
variable, and something similar to its DPADD variable, but (if i
recall) heretofore the "standard" policy has been that libgnumalloc
shouldn't be used on programs outside of the src/gnu tree.


chris