[Top][All Lists]

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

Re: [gnugo-devel] Go as SPEC benchmark?

From: Gunnar Farneback
Subject: Re: [gnugo-devel] Go as SPEC benchmark?
Date: Sat, 16 Nov 2002 00:45:55 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Jim wrote:
> > Since you got a core, can you send us a backtrace?
> >
> > That might be enough for us to figure out the problem.
> >
> > Dan
> Yes, sorry.   - Jim
> 998 zera 715> gdb gnugo core
> HP gdb 1.3.00
> Copyright 1986 - 1999 Free Software Foundation, Inc.
> Hewlett-Packard Wildebeest 1.3.00 (based on GDB 4.17-hpwdb-980821)
> Wildebeest is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under certain
> conditions.  Type "show copying" to see the conditions.  There is
> absolutely no warranty for Wildebeest.  Type "show warranty" for details.
> Wildebeest was built for ia64-hp-hpux11.20
> and target ia64-hp-hpux11.20.
> ..
> Core was generated by `gnugo'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x410d520:0 in clear_move_reasons () at move_reasons.c:111
> 111           move[ii].value                  = 0.0;
> (gdb) bt
> #0  0x410d520:0 in clear_move_reasons () at move_reasons.c:111
> #1  0x40e30b0:0 in reset_engine () at genmove.c:86

This is really strange. As far as I can see that's a place where
nothing can go wrong. But since it does we need to find some more
clues. The most interesting information is the values of the variables
i, j, and ii at the point of the crash.

My best guess is that something goes wrong with the POS macro, like
being picked up from somewhere in the system instead of the one we
define in liberty.h. But I can't see how that could pass without the
compiler complaining.

Btw, I assume this is GNU Go 3.2. Is that correct?


reply via email to

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