xboard: Spurious undo after a new game and first move
I've posted several cases of xboard issuing a spurious undo directive; here is a case where the undo is sent after a new game is started and after the opponent sends his first move. In all, there are fifteen directives sent between the resignation and the undo:
sje wrote:xboard: Spurious undo after a new game and first move
I've posted several cases of xboard issuing a spurious undo directive; here is a case where the undo is sent after a new game is started and after the opponent sends his first move. In all, there are fifteen directives sent between the resignation and the undo:
It is not clear whether "= Forced mode is enabled" is sent from an engine or from WB. If it is the engine then something has to tell the engine to turn off the force mode. Crafty uses a boolean "force" flag to track this. WB is telling the engine to undo because the force mode is still enabled. There might be something wrong with <usermove c4. I use move c2c4 which seems to let WB know what the move is, and indicate both sides agree that force mode is turned off.
Field 1: UTC yyyy-mm-dd
Field 2: UTC hh:mm:ss:mmm
Field 3: "=" is internal message; "<" is output from xboard; ">" is output from Symbolic
Output from both xboard and Symbolic is logged as it is received/sent.
Symbolic processes directives in the order in which they are received. It does not start processing a given directive until the previous directive is processed. Also, it does not start processing a directive while in a search; the search must first complete. This means that it doesn't process an out-of-turn resignation until the search ends and its result (move/draw/resignation) is sent.
There is nothing in the xboard documentation which says that a search must abort if a result is received out of turn. Even the "." (move now) directive does not formally require a search to conclude early.
All text I/O is flushed at the end of each line.
Summary: Just because an xboard directive is echoed to the log file doesn't mean that Symbolic has started its processing.
xboard should never send an undo directive when connected to an ICS when the ICS has been configured with "no takeback". This would eliminate all the spurious undo directive instances reported to date.
xboard should wait for a pong for every ping it sends. Otherwise, why send the ping in the first place?
D Sceviour wrote:It is not clear whether "= Forced mode is enabled" is sent from an engine or from WB. If it is the engine then something has to tell the engine to turn off the force mode. Crafty uses a boolean "force" flag to track this. WB is telling the engine to undo because the force mode is still enabled. There might be something wrong with <usermove c4. I use move c2c4 which seems to let WB know what the move is, and indicate both sides agree that force mode is turned off.
and move directives, still without waiting for a pong 12. Eventually, Symbolic sends pong 12 and pong 13, but by then it would be too late if Symbolic had not ignored the undo directive.
sje wrote:Decoding key for Symbolic's log file output:
Field 1: UTC yyyy-mm-dd
Field 2: UTC hh:mm:ss:mmm
Field 3: "=" is internal message; "<" is output from xboard; ">" is output from Symbolic
Output from both xboard and Symbolic is logged as it is received/sent.
Symbolic processes directives in the order in which they are received. It does not start processing a given directive until the previous directive is processed. Also, it does not start processing a directive while in a search; the search must first complete. This means that it doesn't process an out-of-turn resignation until the search ends and its result (move/draw/resignation) is sent.
There is nothing in the xboard documentation which says that a search must abort if a result is received out of turn. Even the "." (move now) directive does not formally require a search to conclude early.
All text I/O is flushed at the end of each line.
Summary: Just because an xboard directive is echoed to the log file doesn't mean that Symbolic has started its processing.
xboard should never send an undo directive when connected to an ICS when the ICS has been configured with "no takeback". This would eliminate all the spurious undo directive instances reported to date.
xboard should wait for a pong for every ping it sends. Otherwise, why send the ping in the first place?
It looks to me like you sent a move after the result and new commands. a move from the previous game, even after the new game was started and c4 was sent to you???
Yes, he did, but that is allowed. XBoard should have realized the move belonged to the previous game because it came before the pong.
This problem was reported before, and the code in XBoard handling it seems pretty sick. I am not sure what exactly it is supposed to do (I mean, why would you ever want to undo moves in zippy mode?) So fixing this would probably break other things.
Getting xboard to run on a Mac like it runs under Linux requires use of the third party macports package. For various reasons, there are a huge number of dependencies generated in macports when xboard is installed. One of these is the openssl package, and within that package is some odd assembly language source, and some of that source uses an unusual opcode mnemonic. Unfortunately this mnemonic isn't supported by the assembler on Macs stuck at OS/X 10.7.5 or earlier because of Apple's refusal to support development tools or any other software on machines which are a single day more than five years old.
There might be some work-around eventually supplied by the macports guys, but I'm not holding my breath waiting for it to show. And it's disappointing that the macports crew claims support of OS/X 10.7.5 and earlier OS/X versions without having actually done any relevant, up-to-date testing. So I've pulled macports and xboard from my affected machines, leaving it only on the one OS/X 10.11.2 machine which connects to FICS and ICC. I'll pull it there, too, as soon as I get icsdrone up and running.
bob wrote:It looks to me like you sent a move after the result and new commands. a move from the previous game, even after the new game was started and c4 was sent to you???
The move was sent as soon as the search completed. This is always allowed, according to the documentation. Symbolic didn't start a new game until after it processed the new directive.
Symbolic has the class TokenList, a container for a two-way linked list of strings. It includes the instance method Arg(const unsigned int n) which returns the zero origin nth string. For each text line received from xboard, Symbolic creates an empty instance of TokenList and then loads it with white space separated tokens via its SimpleLoad instance method. This is a well-tested routine and has had almost no problems running successfully many thousands of times.
The exceptions, of which there have been perhaps three or four, seem to be correlated with out-of-turn resignations and the undo issue. Each time, the Arg method triggers an internal abort when it detects that the list contains fewer tokens than expected. In these cases, the first token is recognized as a valid xboard directive, but there is at least one parameter token missing.
Unfortunately, the exact input string was not output to Symbolic's log file before the internal abort was executed. I have since changed the code to fix this and am waiting for the bug to reappear.
The directive, whatever it was, came at the point where xboard should have sent a time/otim/usermove directive sequence. Perhaps a bogus result directive got sent. A line consisting entirely of white space might also be a problem.
