[Top][All Lists]

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

Re: [gnugo-devel] disconnect crash (was dynamic connection status)

From: Gunnar Farneback
Subject: Re: [gnugo-devel] disconnect crash (was dynamic connection status)
Date: Fri, 18 Jan 2002 17:25:31 +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)

Trevor wrote:
> The problem is with simple_ladder not dealing well with a double-ko
> situation, causing a stack overflow as it flips the kos over & over.
> So, not strictly in the connection code, but that's the only code
> that calls simple_ladder, so this crash can't occur in play.
> I'm going to pass this bug off to someone more familiar with the
> simple_ladder code & komaster.

The komaster scheme is intended to stop exactly this from occuring, so
obviously there are two possibilities:

1. simple_ladder() does not handle the komaster correctly.

2. The komaster scheme doesn't work as expected.

Fortunately it's easy to test case 2 since we still have a pair of
alternative komaster schemes implemented in board.c. It turns out that
neither of the alternative schemes have this particular problem, so
the conclusion must be that KOMASTER_SCHEME 1 is broken.

One obvious question is why we haven't seen this problem in the
ordinary reading code. The answer is that the ko depth limit has hid
the bug from being found, but it has been there all the time. To see
that, run --decide-string D9 on this sgf file:

GN[White (W) vs. Black (B)]
SY[Cgoban 1.9.2]TM[5:00:00(5x1:00)];AW[da][fa][db][eb][dc][fc][dd][ed]

In the output you'll see invalid ko captures. I've traced it down to
this part of komaster_trymove():

  /* First we check whether the ko claimed by komaster has been
   * resolved. If that is the case, we revert komaster to EMPTY.
   * The ko has been resolved in favor of the komaster if it has
   * been filled, or if it is no longer a ko and an opponent move
   * there is suicide. If komaster == GRAY we don't remember who
   * owns the ko so we have to try both colors.
  if (komaster != EMPTY
      && (IS_STONE(board[kom_pos])
          || (komaster != GRAY
              && !is_ko(kom_pos, OTHER_COLOR(komaster), NULL)
              && is_suicide(kom_pos, OTHER_COLOR(komaster)))
          || (komaster == GRAY
              && !is_ko(kom_pos, BLACK, NULL)
              && !is_ko(kom_pos, WHITE, NULL)
              && (is_suicide(kom_pos, BLACK)
                  || is_suicide(kom_pos, WHITE))))) {
    komaster = EMPTY;
    kom_pos = 0;

The logic in the komaster == GRAY case is simply wrong but I don't
have a solution available. Until someone can come up with a fix for
this I suggest we change KOMASTER_SCHEME to 2 or 3.


reply via email to

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