NetBSD Problem Report #3126

Received: (qmail-queue invoked from smtpd); 18 Jan 1997 18:19:37 -0000
Message-Id: <199701181814.TAA02451@wipux2.wifo.uni-mannheim.de>
Date: Sat, 18 Jan 1997 19:14:05 +0100 (MET)
From: Andrew Wheadon <andrew@wipux2.wifo.uni-mannheim.de>
Reply-To: andrew@wipux2.wifo.uni-mannheim.de
To: gnats-bugs@gnats.netbsd.org
Subject: games/gomoku segfaults
X-Send-Pr-Version: 3.95

>Number:         3126
>Category:       bin
>Synopsis:       ./gomoku runs out of memory and segfaults
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 18 10:20:02 +0000 1997
>Closed-Date:    Mon Aug 08 03:25:27 +0000 2016
>Last-Modified:  Mon Aug 08 03:25:27 +0000 2016
>Originator:     Andrew Wheadon
>Release:        16.1.97
>Organization:
The cost of living hasn't affected its popularity. (Mark Twain)
current	release=doc host=netbsd.wifo.uni-mannheim.de \ "NetBSD-current mirror"
hostbase=/mit/ftp/pub/NetBSD base=/usr prefix=/usr backup delete use-rel-suffix
>Environment:

System: NetBSD wipux2.wifo.uni-mannheim.de 1.2B NetBSD 1.2B (WIPOOL) #0: Sat Jan 11 03:34:48 MET 1997 toor@wipux2.wifo.uni-mannheim.de:/src/src/sys/arch/i386/compile/WIPOOL i386


>Description:
When playing gomoku it will usually start using up masses of memory
after about 8 turns (4 each), it will then sit there calculating 
for about 5 minutes before it runs out of memory (if ulimit is set
to 16MB), after which it will segfault. (it failed 4 out of 5 times).

>How-To-Repeat:
	play gomoku until it starts thinking for ages and then
	watch it growing with 'top' until it Segfaults.

>Fix:
unlimit and add lots of memory to machine or 
free memory after each game (not sufficient since it will often
use up too much memory in one game)
check whether malloc returns NULL and do appropriate action in 
pickmove.c (unluckily appropriate action means more than just "continue;")
or
make it more intelligent or
make the board smaller (not easy either)
or contact author for newer version.
rm -fr gomoku


>Release-Note:
>Audit-Trail:

From: Andrew Wheadon <andrew@wipux2.wifo.uni-mannheim.de>
To: gnats-bugs@gnats.netbsd.org
Cc:  Subject: Re: bin/3126: games/gomoku segfaults
Date: Sat, 18 Jan 1997 20:40:40 +0100 (MET)

 I forgot to post reliable examples which can be followed:

 Two reliable example:
 you play white
 Computer	You
 K10 (computer always starts with K10 if black)
 		J7 (i.e. don't play near computer)
 J9  (random)
 		K7
 G7 (computer hopes)
 		H8 (spoil computers hope)
 M12 (computer tries force)
 		M7 (ignore computers threat)
 Segfaults.
 alternate (but same general tactic)
 you play white
 K10
 	J7
 H8 (random)
 	K7
 G7
 	J9
 F6
 	M7
 Segfaults.

 Except for once the computer always played like this.
 Generally ignore it the first two goes, then fill in the
 hole in it's attempted diagonal row and then put a piece
 along your row leaving one hole in it and placing the piece
 away from the diagonal row belonging to the computer.

 -- 
 The cost of living hasn't affected its popularity. (Mark Twain)
 current	release=doc host=netbsd.wifo.uni-mannheim.de \ "NetBSD-current mirror"
 hostbase=/mit/ftp/pub/NetBSD base=/usr prefix=/usr backup delete use-rel-suffix

From: Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de>
To: jsm28@cam.ac.uk
Cc: gnats-bugs@gnats.netbsd.org,
        Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>
Subject: Re: bin/3126: gomoku segfaulting?
Date: Tue, 27 Jul 1999 04:01:44 +0200 (MET DST)

 Hi,

 I'm digging through the NetBSD PR database a bit, and found Pr 3126:
 ./gomoku runs out of memory and segfaults (see
 http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=3126). 

 I was not able to reproduce this, but then, the given example didn't work
 for me, and I don't know more about that game... maybe you do? 
 What do you think about the PR?


  - Hubert

 -- 
 NetBSD - Better for your uptime than Viagra


From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/3126: gomoku segfaulting?
Date: Tue, 27 Jul 1999 18:30:32 +0100 (BST)

 On Tue, 27 Jul 1999, Hubert Feyrer wrote:

 > I'm digging through the NetBSD PR database a bit, and found Pr 3126:
 > ./gomoku runs out of memory and segfaults (see
 > http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=3126). 
 > 
 > I was not able to reproduce this, but then, the given example didn't work
 > for me, and I don't know more about that game... maybe you do? 
 > What do you think about the PR?

 I'm reasonably sure that the last time I tested it, it still easily uses
 16M of memory (and doesn't check allocation failure - that bit is fixed in
 my 10K lines of unmerged patches).  As for fixing the memory consumption
 or algorithm - I don't claim to be sufficiently good at gomoku to tell
 what is good enough for computer play.  I have the following from Paul
 Janzen of OpenBSD (pjanzen@foatdi.harvard.edu) on the algorithm (as of
 last August, but he doesn't seem to have worked on it since):

   gomoku is not "done", in that the algorithm still totally sucks (I really
   need to go looking for a new BSD-compatible algorithm.  For what it's worth,
   emacs' gomoku also has a lousy algorithm, but at least it's fast.)  For
   this reason I've held off merging the latest NetBSD gomoku, since most of
   the code I hope will disappear.  However, I have thrown in an improved
   player input scheme, based on the one by esr in "bs".

 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk

From: David Holland <dholland@eecs.harvard.edu>
To: gnats-bugs@gnats.netbsd.org
Cc: 
Subject: Re: bin/3126: ./gomoku runs out of memory and segfaults
Date: Sat, 19 Jan 2008 15:52:37 -0500

 Update:

 In -current it apparently no longer segfaults, but if you crank down
 limits (or, presumably, run on a system without much ram) it will run
 out of memory very promptly and exit. (And it prints "Out of memory"
 in such a way that it's immediately erased by endwin(), so you can't
 tell what happened...)

 It also still uses a really stupid move choice algorithm. :-|

 -- 
    - David A. Holland / dholland@eecs.harvard.edu

From: David Holland <dholland@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/3126
Date: Mon, 8 Aug 2016 02:04:38 +0000

 Commits for PRs under 10000 aren't autoforwarded any more.

    ------

 From: "David A. Holland" <dholland@netbsd.org>
 To: source-changes@NetBSD.org
 Subject: CVS commit: src/games/gomoku
 Date: Sun, 12 Jun 2016 02:15:26 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Sun Jun 12 02:15:26 UTC 2016

 Modified Files:
 	src/games/gomoku: main.c

 Log Message:
 Fix the out-of-memory behavior so the message doesn't disappear under
 endwin(). Related to PR 3126.


 To generate a diff of this commit:
 cvs rdiff -u -r1.26 -r1.27 src/games/gomoku/main.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 08 Aug 2016 03:25:27 +0000
State-Changed-Why:
It no longer segfaults. It's still dumb, but I've moved that issue to
a project page: http://wiki.netbsd.org/projects/project/gomoku-brain/


>Unformatted:

Home	PR Database Search