Bug in xboard's protover 2 SAN output

[sje]

I don't really care about this "bug" at all. Crafty knows when it is mated, and does not even parse the # flag anyway, it just strips it off. It does pay attention to the check indicator (+) and uses that to disambiguate moves, as if you give a +, it can immediately cull all non-checking moves before trying to match your input to the move generator's output.

The old Symbolic and it predecessors had pages of code dedicated to interpreting ambiguous user move input. But it really was out of place for a non-public program, so I killed it in the new Symbolic core. I have no problems typing SAN, and the new 4.3.15 xboard is also (we hope!) capable of canonical SAN I/O.

By the way, there is a bug in xboard 4.3.15 that may/will send a SIGTERM signal immediately after a "quit" even if the client requested no SIGTERM via "feature sigterm=0". HGM is looking at this and has made good progress diagnosing the cause. There is also a minor bug in the documentation where some command line options have one default value in Winboard and a different one in xboard.

It looks like the new xboard/Winboard is fully set up to support UCI with assistance from PolyGlot. So Crafty can be run as a UCI engine, like it or not. I may use xboard/PolyGlot to test the UCI command processor in the new Symbolic core, but I've got to shake more bugs out of my program first.

[hgm]

Note that the feature that requests no SIGTERM to be sent pertains really to the SIGTERM that XBoard would send during the game, when it wants to draw the engines attention to a command it sent while the engine is thinking. The SIGTERM we are talking about now, which is sent after the 'quit' command, belongs in different category. Its purpose is not to draw the engine's attention, but to kill it. The bug is that SIGTERM is used in stead of SIGKILL here, and that there is too little pause here between the quit and the signal. It is not something that can be switched off by any feature command.

All this is a result from a change made in Winboard_x by Alessndro Scotti, which I was not aware of, and therefore was not back-ported to XBoard yet.

[bob]

I don't really care about this "bug" at all. Crafty knows when it is mated, and does not even parse the # flag anyway, it just strips it off. It does pay attention to the check indicator (+) and uses that to disambiguate moves, as if you give a +, it can immediately cull all non-checking moves before trying to match your input to the move generator's output.

The old Symbolic and it predecessors had pages of code dedicated to interpreting ambiguous user move input. But it really was out of place for a non-public program, so I killed it in the new Symbolic core. I have no problems typing SAN, and the new 4.3.15 xboard is also (we hope!) capable of canonical SAN I/O.

By the way, there is a bug in xboard 4.3.15 that may/will send a SIGTERM signal immediately after a "quit" even if the client requested no SIGTERM via "feature sigterm=0". HGM is looking at this and has made good progress diagnosing the cause. There is also a minor bug in the documentation where some command line options have one default value in Winboard and a different one in xboard.

It looks like the new xboard/Winboard is fully set up to support UCI with assistance from PolyGlot. So Crafty can be run as a UCI engine, like it or not. I may use xboard/PolyGlot to test the UCI command processor in the new Symbolic core, but I've got to shake more bugs out of my program first.

You can certainly use a UCI-to-WINBOARD type gadget, but it really does hurt the engine because of the way moves kept getting stuffed in...

[sje]

The bug is that SIGTERM is used in stead of SIGKILL here, and that there is too little pause here between the quit and the signal. It is not something that can be switched off by any feature command.

The temporary work-around for "sigterm=0" programs is to ignore the SIGTERM by executing

Code: Select all

  signal(SIGTERM, SIG_IGN);

Of course, the above won't work as a defense against the mighty SIGKILL.

[sje]

It looks like the new xboard/Winboard is fully set up to support UCI with assistance from PolyGlot. So Crafty can be run as a UCI engine, like it or not. I may use xboard/PolyGlot to test the UCI command processor in the new Symbolic core, but I've got to shake more bugs out of my program first.

You can certainly use a UCI-to-WINBOARD type gadget, but it really does hurt the engine because of the way moves kept getting stuffed in...

The choice of whether or not to use move stuffing is the operator's as he's the guy specifying the command line parameters when starting the GUI. Personally, I wouldn't allow it unless I had written the GUI myself and supplied it with my own book and tablebases.

I haven't (yet) tried PolyGlot and so I don't know exactly how faithfully it maps between UCI and xboard protocols. Perhaps others can comment more authoritatively on this issue.

[hgm]

I uploaded an experimental XBoard version to my website ( http://home.hccnet.nl/h.g.muller/XB16.tar.gz ), where I addressed the SIGTERM problem. I changed it to code that should send a SIGKILL n stead, but only if the engine has not terminated by itself 3 sec after receiving ' quit' from XBoard.

It also should support the options -delayAfterQuit T and -delayBeforeQuit T, where T is a number of seconds (which already existed in WinBoard).

To this end I added the code below in DestroyChildProcess() in xboard.c. (AlarmCallBack is a dummy routine that returns without doing anything.) Perhaps you can try it out; these are things that are difficult to test, as most engines would not care at all whatever happened here, but yours seems to report nicely.

Code: Select all

    if (signalType == 10) { // [HGM] kill: if it does not terminate in 3 sec, kill

	signal(SIGALRM, AlarmCallBack);

	alarm(3);

	if(wait((int *) 0) == -1) { // process does not terminate on its own accord

	    kill(cp->pid, SIGKILL); // kill it forcefully

	    wait((int *) 0);        // and wait again

	}

    } else {

[krazyken]

Early results for me indicate that it clears up the trouble I reported of engines being left running after xboard quits.

One Compile note, in uci.c there is
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>

On Mac OS X #include <malloc.h> will not work and breaks compiling. It is redundant anyways with the #include <stdlib.h> I can't say for sure about other *nix platforms, but I suspect you should be able to do away with it completely.

[sje]

Early results for me indicate that it clears up the trouble I reported of engines being left running after xboard quits.

One Compile note, in uci.c there is
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>

On Mac OS X #include <malloc.h> will not work and breaks compiling. It is redundant anyways with the #include <stdlib.h> I can't say for sure about other *nix platforms, but I suspect you should be able to do away with it completely.

I noted this earlier; an empty malloc.h file fixes the problem.

The malloc.h file is pre-ANSI C (I think) and was dropped long ago for most platforms. The stdlib.h file is the modern replacement, also known as "cstdlib" to us C++ coders.

--------

Three seconds of pre-kill delay may not be enough in some cases. My program just might be running a statistics summary on a 16 GB transposition table! Perhaps there should be a feature "killdelay=0" which sets the delay to an hour just as "done=0" adds an hour delay to the feature declaration input timeout.

[hgm]

Try -delayAfterQuit 3600 . With a potential maximum of 2G sec or nearly 500000 hours in a 32-bit int, I don't think there is a real need to be able to set the delay to infinite.

I don't think it is a good idea to offer the possibility for engines to switch this off: everyone would do it by default, and the measure would lose its effectiveness. The decision to switch it off must come from the user. Users can install the engine in their tournament manager so that it is always run with the XBoard option to stretch the kill delay to a value that is reasonable for the particular engine.

[sje]

I'm starting to think that we need something new here instead of using pipes for communication. There are too many issues of timing and process control that aren't handled well with simple piping, likely because they can't be handled well with simple piping.

How about having a chess program implemented as a typical service daemon and using the typical socket based listen/accept/connect handshake and data transfer protocol? This model works so very well in many contexts and I think it would do fine for chess programs also.