Bug in xboard's protover 2 SAN output

[sje]

[ Reposted from TalkChess http://www.talkchess.com/forum/viewtopic.php?t=27285 ]

I was surprised to see this one:
[D] r1b1kb1r/p2p1ppp/4p3/1p2PP2/Pn2K1n1/2N4N/1PpP1qPP/R1B4R b kq - 8 13

The old Symbolic is playing White against the new Symbolic playing Black through xboard in a test game.

From the logs:

White sees the mate in one and sends:

Code: Select all

2009.04.01 17:30:31.244495 > move exf5#
2009.04.01 17:30:31.244536 > 0-1 {White is checkmated}


Black, however, gets:

Code: Select all

2009.04.01 17:30:31.247 < time 5925
2009.04.01 17:30:31.258 < otim 3821
2009.04.01 17:30:31.269 < usermove exf5+


For some unknown reason, xboard-4.2.7 is changing the mate indicator into a check indicator. This messes with the new Symbolic who is assuming that xboard understands SAN.

Is there a newer version of xboard that I should be using?

[sje]

I downloaded 4.3.15 and got it running on an Intel Mac with Mac OS/X 10.5.6.

The make failed at two points:

1) There is no malloc.h file in the Mac OS/X 10.5.6 SDK. Simple fix: "touch malloc.h" to make an empty file.

2) The man page installation directories specified by the makefile do not exist in Mac OS/X 10.5.6. I can live without the extra pages, so I let this fail.


First impressions:

1) The engine analysis output window is a big improvement over the one line display in some older versions.

2) Adjudication should probably not be turned on by default.

[sje]

Also with xboard 4.3.15, the GUI is sending a SIGTERM signal even if was disabled with "feature sigterm=0".

The improper raise happens immediately after the end of an automated match:

Code: Select all

2009.04.01 23:11:08.338 < ping 20
2009.04.01 23:11:08.348 > pong 20
2009.04.01 23:11:08.408 < quit
2009.04.01 23:11:08.408 Got SIGTERM


[H.G.Muller]

2) Adjudication should probably not be turned on by default.

I was indeed in doubt about that. I should have mde it such that the are turned off by default, as my usual policy is to reproduce the old behavior unless it is explicitly specified (by new command-line option) to do things differently. Indeed, in WinBoard this is what I do.

But XBoard does not remember its settings like WinBoard does. So although there is a menu to switch on the adjudications, you would have to do it every time anew when you start up XBoard. I figured that a a result most people would run with the option switched off out of laziness, which would be kind of a waste, as I feel that what most people would want if they thought bout it is to run wth the option switched on. So I decided to deviate from my own policy.

I feel backed on this by the FIDE rules, which specify a game is finished when there is a checkmate, stalemate or insufficientt mating material on the board. And people really have no right to complain if the GUI maintains FIDE rules, even if it maintains them more strictly tht a previous version did. IMO it should really be considered a bug that the previous versions did allow a game to continue after the mate. But this was of course a conscious design decision, given the fact that mates could not be detected reliably, due to the 'limitation' of not beng e.p. aware. And the 'reproduce old behaviour as much as possible' does of course not apply to bug fixing.

[sje]

The main point of my complaint is that the program getting checkmated (or stalemated or whatever) never gets to see the move that ends the game. So its saved copy of the game will differ from that of its opponent. I'd like to think that adherence to FIDE rules means that both players come away from the table with the same scoresheets.

[H.G.Muller]

Also with xboard 4.3.15, the GUI is sending a SIGTERM signal even if was disabled with "feature sigterm=0".

The improper raise happens immediately after the end of an automated match:

Code: Select all

2009.04.01 23:11:08.338 < ping 20
2009.04.01 23:11:08.348 > pong 20
2009.04.01 23:11:08.408 < quit
2009.04.01 23:11:08.408 Got SIGTERM


This is more serious. It seems that Alessandro Scotti in Winboard_x has changed some calls from the backend to DestoyChildProcess, which originally used a boolean argument to indicate if SIGTERM should be used or not, to also use integer values 9 or 10 as special codes to kill off programs that say they dont want to receive sIGTERM, but subsequently refuse to quit, and keep hanging.

This of course has to be parallelled by a change in the front end, or it produces unwanted behavior. Indeed, in winboard.c the code of DestroyChildProcess now contains:

Code: Select all

    /* [AS] Special termination modes for misbehaving programs... */
    if( signal == 9 ) {
        result = TerminateProcess( cp->hProcess, 0 );

        if ( appData.debugMode) {
            fprintf( debugFP, "Terminating process %u, result=%d\n", cp->pid, result );
        }
    }
    else if( signal == 10 ) {
        DWORD dw = WaitForSingleObject( cp->hProcess, 3*1000 ); // Wait 3 seconds at most

        if( dw != WAIT_OBJECT_0 ) {
            result = TerminateProcess( cp->hProcess, 0 );

            if ( appData.debugMode) {
                fprintf( debugFP, "Process %u still alive after timeout, killing... result=%d\n", cp->pid, result );
            }

        }
    }


As I was not aware of this, I did not back-port that to xboard.c yet. So XBoard considers the 9 and 10 simply as TRUE, and will immediately send SIGTERM to the process. In as far as I understand the Windows code, the intended behaviour is actually to send SIGKILL without or with a 3-sec delay, respectively. In the next reease I will incude that.

For programs that do not misbehave, but terminate on their own accord after receiving 'quit', it is probably not too much of a problem; even if they die from the SIGTERM, a SIGKILL would not make them fare any better. The only poblem might be that the 3-sec delay is not implemeted, which might cause data loss if something had to be saved to disk ater 'quit'. In WinBoard this period can even be tuned with the option -delayAfterQuit, but I did not port that option to XBoard either, so it cannot be used as a work-around.

Thanks for flagging the bug.

[H.G.Muller]

The main point of my complaint is that the program getting checkmated (or stalemated or whatever) never gets to see the move that ends the game. So its saved copy of the game will differ from that of its opponent. I'd like to think that adherence to FIDE rules means that both players come away from the table with the same scoresheets.

You are right, this is not as it should be. It is not related to the question if the mate adjudication should be on or off by default, though: even if it is on, the opponent has the right to see the move by which it was checkmated.

In the next release I will make sure the move is sent before the game is ended by a checkmate or stalemate adjudication. (I already had to fix a similar problem earlier, because the user did not get to see the final move on the display!)

I am not so sure if it is a good idea, though, to do this for all adjudications. Many engines have uninterruptable search. So if you send them he opponent move which brings a 3-fold repetition on the board, an then send them the move before sending a 'result' command, they start thinking on the replay. And the 'result' command then get simply queued in the pipe untill they produce the move, which can take several minutes at long TC. This then might cause the move to come in the next game (in match mode), where it will cause forfeit due to an illegal move, in engnes that do not support ping. (The current treatment of a resignation also causes this problem.)

Perhaps I should put the engine in force mode before sending it a move that will lead to adjudication!

The 'resign' problem is more tricky: many engines resign in the opponent's turn, after sending a move. If they do that, XBoard cannot know that they are going to resign at the time it gets the move, and will faithfully pass it on to the opponent, which will then start thinking. Then a resignation comes in. Perhaps I should only pass on such out-of-turn resignations only after the opponent has come up with its reply, when that opponent does not support ping. It seems a bit silly to wait for a move when the game is already finished (and would again lead to the games as seen by the two engines not being identical), but I am not sure what else I could do. The resigner will most likely not accept another move after it resigned... Perhap I should send 'force' + 'undo' to the engine doing the extra move, before sending it the RESULT command that informs it of the resignation. But not al engines implement 'undo'. (That would be their problem, though...) This is all awfully cumbersome, just to cater to engines that do not support ping (as every engine really should).