Another spurious xboard undo

[sje]

Another spurious xboard undo

This one on FICS occurred after a new game had started and after the opponent, now playing White, sent a move.

As usual, the opponent had resigned out of turn, not waiting for Symbolic to play its move. Also, the opponent started a new game before Symbolic could play its move. Further, the opponent played a move before Symbolic could play its move.

Until a fixed-up version of xboard is pushed through MacPorts, I am going to take a caveman approach and simply start handing out a +noplay ICS directive to any opponent who does the above triple jam. I have wasted way too much time on this already.

[D Sceviour]

Another spurious xboard undo

This one on FICS occurred after a new game had started and after the opponent, now playing White, sent a move.

As usual, the opponent had resigned out of turn, not waiting for Symbolic to play its move. Also, the opponent started a new game before Symbolic could play its move. Further, the opponent played a move before Symbolic could play its move.

Until a fixed-up version of xboard is pushed through MacPorts, I am going to take a caveman approach and simply start handing out a +noplay ICS directive to any opponent who does the above triple jam. I have wasted way too much time on this already.

There are a lot of engines that use xboard and still successfully handle the undo. The problem may be in Symbolic and not xboard. Perhaps you could post the code section that handles the undo.

[sje]

I've already gone through this, more than once. The bugs are with xboard, including passing directives while not waiting for pong responses. The time budget has been exhausted, therefore, a +noplay until a new xboard appears in MacPorts.

[JoshPettus]

Why is a release on macports going to magically solve the problem? You do know it's the same code right?

The differences between the app and a normal Unix install is a little bit of GTK mac integration code and the fact the app is inherently not in PATH. Nothing to do with the undo code.

If you don't want to wait for macports to update, you can download all the dependencies through macports (gtk2, librsvg, may be forgetting some but configure will let you know). Then compile with CFLAGS="-I/macports/prefix/include -L/macports/prefix/lib"

make
sudo make install
(it will install on system as oppose to macports prefix folder, but will work fine)

[sje]

I'm referring to a new version of xboard which has the undo bug fixed. When such is pushed through MacPorts, it will benefit all MacPorts users and not just me.

Also, the xboard dependency set is not insignificant. It takes about a half hour for import and compilation on a multicore machine.

[JoshPettus]

Ah I understand you now. You are absolutely right, the dependencies are a pain in the rear, especially when macports has to compile them rather then install binaries.

[sje]

I did find a mistake in my code: The specially coded diagnostic routine which reported a spurious undo tried to print the second token of the directive string instead of the first. This triggered the token list exhausted diagnostic, but its output didn't make it to the log file before the other thread killed the process. I added some timer delays to push the log messages out prior to an abort, and this revealed the problem.

Things might have been a little easier if xboard did not grab an engine's stderr output, keeping it from the console. That would make death messages simpler to see.

Symbolic does have a Die() routine, and this handles all abnormal, self-directed terminations. It outputs a one line message to stderr (which might not be seen if grabbed prior) and also to a file named CauseOfDeath. But it's just one line and it can't dump an arbitrary data structure, just a string.

Code: Select all

void Die(const std::string& placeofdeath, const std::string& causeofdeath)
{
  std::ofstream deathofs("CauseOfDeath");
  std::ostringstream oss;

  Beep();
  oss << "Fatal error: (" << placeofdeath << ") " << causeofdeath << "\n";
  deathofs << oss.str() << std::flush;
  WriteStdLog(oss.str());
  abort();
}

[hgm]

I just pushed a new XBoard commit to hgm.nubati.net that should fix these spurious undos for ping-supporting engine. The ping-unbalance created when the last engine think of the previous game is aborted will cause incoming moves to be totally ignored until the ping balance is restored.

Before, some moves during ping imbalance were countered with "undo", presumably because aborting engine think can also occur in the middle of a game, when the user switches to EditGame while the engine is thinking. In this case a move produced by the engine will have to be undone to keep engine and GUI in phase. I now made an independent mechanism for that, based on setting of an 'undoFlag' when the EditGameEvent occurs, which also freezes the user interface until the engine replies to an accompanying ping, and clearing the fag (and thawing the UI) when the pong response arrives. Moves arriving when this undoFlag is set will get an "undo" reply.

The existing mechanism to distinguish these two cases, based on the gameMode being BeginningOfGame or not, just wasn't reliable. This gameMode is left as soon as the first move is played, and when the engine had black in the new game, it could happen that the opponent's move already arrived when the engine was still thinking for the previous game, so that when it finally moved the gameMode had already changed away from BeginningOfGame, and evoked an (spurious) 'undo' response.