Exception raise when game is draw #379
Comments
|
Intresting. I guess the second part is expected for However the first shouldn't happen, of course. Which engine did you use? Or alternatively, |
|
It is with Stockfish (UCI) vs Phalanx (xboard). I get some exceptions like the one below, without being the side effect of a first exception. So maybe Phalanx misbehaves as an xboard engine, I will try to track this down.
|
|
Some speculation, looking at the source code of Phalanx: In some cases it prints /* COMMAND: remove (xboard) */
»»»»if( strncmp( Inp, "remove", 6 ) == 0 )
»»»»{
»»»»»»»»if( Flag.ponder >= 2 ) { Abort = 1; return 0; }
»»»»»»»»if( Counter > 1 )
»»»»»»»»{
»»»»»»»»»»»»undo_move( & G[Counter-1].m );
»»»»»»»»»»»»undo_move( & G[Counter-1].m );
»»»»»»»»»»»»if(Flag.xboard<2) puts("move back");
»»»»»»»»»»»»if( Flag.machine_color != 0 )
»»»»»»»»»»»»Flag.machine_color = enemy(Color);
»»»»»»»»}
»»»»»»»»else puts("cannot remove");
»»»»»»»»Inp[0]='\0'; return 1;
»»»»} |
|
I don't think it is the cause. There is no reason a 'remove' command is sent in my program. |
|
Are you playing multiple games back to back, by any chance? If so, |
|
I instantiate a new Board for every game, so I doubt this is it. |
|
The board object isn't used to determine this, only the Edit: Never mind, you're right. |
|
Here is output preceding an error (Phalanx playing against itself):
Please note that I think the bug raises when a draw is met. The code seems to try to handle a move
|
|
I switched to Crafty to check with a reliable engine. Here is an error I got. To resign is handled in engine.py at line 1723, I don't know why this crashes.
|
|
Maybe I should have opened a new issue for the 'resign' case, but for the previous one, the issue is still present (python-chess version 27.2). See below, Stockfish vs Phalanx :
|
|
I may have an explanation : InvalidStateError means set_result() was already called for the Future. And then the received line 'move c6b5' is handled and triggers at line 1748 |
|
Thanks, these logs help a lot. So apparently engines declare the game as over (1/2-1/2, resign) but then send a move anyway 😢. Not so important: Is this even valid according to the spec? It doesn't make sense to me, and indeed Either way we have to deal with it. That's problematic, because we don't really know when the command is complete. Will a move come, or not? Maybe an extra ping/pong cycle is required to make sure. |
|
I read two versions of the spec, and sending a move after a result should not be allowed, this is non sense (and confirmed by the code in appendix C). I looked quickly at Phalanx code and maybe it is buggy, sending an extra move. The idea is to harden the code so that self.result.set_result() is not called twice for an unique Future; once you are sure a game is over, you may dismiss everything else from the engine.
Which means Future result was set twice after a game ended by a draw. |
|
Ok ... it wasn't as simple as ignoring the extra move (because it could slip over to the next communication, or get |
When making a match engine, I get a raised exception when the game is a draw :
The text was updated successfully, but these errors were encountered: