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:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.