Duck Chess

[rgrosz789]

That is because this way 'debug' is an option to mayhemduck. To make UCI2WB more talkative, you should give it as an option to UCI2WB, like:

xboard -debug -fcp "uci2wb debug mayhemduck" -variant duck

Today I got the same "syntax error" with mayhemduck that I was getting with fairymax:

locale = en_US.UTF-8
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
shuffleOpenings = 0
shuffleOpenings = 0
Version: xboard 4.9.1 + uci2wb ()
Reset(1, 0) from gameMode 0
recognized 'duck' (-1) as variant duck
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") uci2wb debug mayhemduck
420 >first : xboard
protover 2
422 <first : # queue 'protover', searching=0
422 <first : # command protover
422 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
422 >first : accepted setboard
422 >first : accepted usermove
422 >first : accepted debug
422 >first : accepted ping
422 >first : accepted name
422 >first : accepted reuse
422 >first : accepted exclude
422 >first : accepted pause
422 >first : accepted sigint
422 >first : accepted sigterm
422 >first : accepted done
422 <first : feature option="UCI2WB debug output -check 1"
422 >first : accepted option
422 <first : feature option="ponder always -check 0"
422 >first : accepted option
422 <first : # uci
424 <first : # engine said: /usr/games/mayhemduck: 1: Syntax error: "(" unexpected
424 <first : tellusererror UCI2WB: mayhemduck died on me
GameEnds(30, xboard exit, 2)


For no obvious reason, the error NO longer occurs with fairymax - I am so confused ...

[hgm]

I am confused too. What appears to happen is clear from the debug file: UCI2WB sends the command 'uci' to mayhemduck, but instead of the normal reply the process that was supposed to execute mayhemduch replies with this 'Syntax error' message. I don't believe that is a message that mayhemduck prints (since we got the same message from Fairy-Max, where I am sure it would never print that). So the attempt to start the engine executable after forking off a new process for it apparently failed. The responsible routine in XBoard is this (in usystem.c):

Code: Select all

int
StartChildProcess (char *cmdLine, char *dir, ProcRef *pr, int priority)
{
    char *argv[64], *p;
    int i, pid;
    int to_prog[2], from_prog[2];
    ChildProc *cp;
    char buf[MSG_SIZ];

    if (appData.debugMode) {
	fprintf(debugFP, "StartChildProcess (dir=\"%s\") %s\n",dir, cmdLine);
    }

    /* We do NOT feed the cmdLine to the shell; we just
       parse it into blank-separated arguments in the
       most simple-minded way possible.
       */
    i = 0;
    safeStrCpy(buf, cmdLine, sizeof(buf)/sizeof(buf[0]) );
    p = buf;
    for (;;) {
	while(*p == ' ') p++;
	argv[i++] = p;
	if(*p == '"' || *p == '\'')
	     p = strchr(++argv[i-1], *p);
	else p = strchr(p, ' ');
	if (p == NULL) break;
	*p++ = NULLCHAR;
    }
    argv[i] = NULL;

    SetUpChildIO(to_prog, from_prog);

    if ((pid = fork()) == 0) {
	/* Child process */
	// [HGM] PSWBTM: made order resistant against case where fd of created pipe was 0 or 1
	close(to_prog[1]);     // first close the unused pipe ends
	close(from_prog[0]);
	dup2(to_prog[0], 0);   // to_prog was created first, nd is the only one to use 0 or 1
	dup2(from_prog[1], 1);
	if(to_prog[0] >= 2) close(to_prog[0]); // if 0 or 1, the dup2 already cosed the original
	close(from_prog[1]);                   // and closing again loses one of the pipes!
	if(fileno(stderr) >= 2) // better safe than sorry...
		dup2(1, fileno(stderr)); /* force stderr to the pipe */

	if (dir[0] != NULLCHAR && chdir(dir) != 0) {
	    perror(dir);
	    exit(1);
	}

	nice(priority); // [HGM] nice: adjust priority of engine proc

        execvp(argv[0], argv); // <-------------------------------------------------------------------

	/* If we get here, exec failed */
	perror(argv[0]);
	exit(1);
    }

    /* Parent process */
    close(to_prog[0]);
    close(from_prog[1]);

    cp = (ChildProc *) calloc(1, sizeof(ChildProc));
    cp->kind = CPReal;
    cp->pid = pid;
    cp->fdFrom = from_prog[0];
    cp->fdTo = to_prog[1];
    *pr = (ProcRef) cp;
    return 0;
}

The "if ((pid = fork()) == 0) {}" clause is what the forked-off engine process does. The execvp() I indicated here with a commented 'arrow' would be responsible for starting the engine with the command (and possble arguments) in the array argv[].

It looks like this execvp call fails because argv contains an unexpected parenthesis somewhere. I don't see how that could have gotten there, though: argv[] is filled by the preceding code by splitting up the engine command (supplied as cmdLine, which is printed in the debug file, so we know it to be "uci2wb debug mayhemduck") at the spaces, possibly exempting spaces within quotes (which are not present here).

So it seems we have to debug this the hard way. Can you insert in the code above in the usystem.c file, just above the execvp line:

Code: Select all

printf("a: {%s}\n", argv[0]);
printf("b: {%s}\n", argv[1]);
printf("c: {%s}\n", argv[2]);
printf("d: {%s}\n", argv[3]);

recompile XBoard, and then run it again? This should inform us about what command execvp was trying to execute, in the terminal window from which you start XBoard. So whe could see where these mysterious parentheses it complains about are coming from.

[rgrosz789]

Linux Mint latest: Xboard 4.9.1 finally works properly ! No more Winboard

Game that finally went smooth to the finish line. MayhemDuck 2.1 is just a bug fix version. Hoped to add more strength...

However v2.0 crashed. As Rick pointed out. I don't know why. But after fixes v2.1 works properly. I uploaded the improved version. You can activate debug w/ "debug 1" and deactivate w/ "debug 0" if there's problems. It writes to a file all commands sent in and out.

Also I put all these Linux programs here. Very simple to install: https://github.com/SamuraiDangyo/xboard-helper

I'm trying to figure out why xboard acts differently on my Linux mint systems versus Linux debian. I noticed that I had two copies of uci2wb - one in /usr/games and the other in /usr/local/bin.

The copy in /usr/games was created by xboard-helper.sh - is it supposed to be there?

tar -xf uci2wb-6b6a612.tar.gz
cd uci2wb-6b6a612
gcc -O2 -s UCI2WB.c -lpthread -o UCI2WB
cp UCI2WB /usr/games/uci2wb

[rgrosz789]

It looks like this execvp call fails because argv contains an unexpected parenthesis somewhere. I don't see how that could have gotten there, though: argv[] is filled by the preceding code by splitting up the engine command (supplied as cmdLine, which is printed in the debug file, so we know it to be "uci2wb debug mayhemduck") at the spaces, possibly exempting spaces within quotes (which are not present here).

So it seems we have to debug this the hard way. Can you insert in the code above in the usystem.c file, just above the execvp line:

Code: Select all

printf("a: {%s}\n", argv[0]);
printf("b: {%s}\n", argv[1]);
printf("c: {%s}\n", argv[2]);
printf("d: {%s}\n", argv[3]);

recompile XBoard, and then run it again? This should inform us about what command execvp was trying to execute, in the terminal window from which you start XBoard. So whe could see where these mysterious parentheses it complains about are coming from.

I did all that, and it did NOT make any difference in xboard.debug:

locale = en_US.UTF-8
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
shuffleOpenings = 0
shuffleOpenings = 0
Version: xboard 4.9.1 + uci2wb ()
Reset(1, 0) from gameMode 0
recognized 'duck' (-1) as variant duck
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") uci2wb debug mayhemduck
411 >first : xboard
protover 2
413 <first : # queue 'protover', searching=0
413 <first : # command protover
413 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
413 >first : accepted setboard
413 >first : accepted usermove
413 >first : accepted debug
413 >first : accepted ping
413 >first : accepted name
413 >first : accepted reuse
413 >first : accepted exclude
413 >first : accepted pause
413 >first : accepted sigint
413 >first : accepted sigterm
413 >first : accepted done
413 <first : feature option="UCI2WB debug output -check 1"
413 >first : accepted option
413 <first : feature option="ponder always -check 0"
414 >first : accepted option
414 <first : # uci
416 <first : # engine said: /usr/games/mayhemduck: 1: Syntax error: "(" unexpected
416 <first : tellusererror UCI2WB: mayhemduck died on me
GameEnds(30, xboard exit, 2)

[hgm]

Oh wait! I was stupid. The error message does not occur in the process forked off by XBoard (which starts UCI2WB), but by the process forked off by UCI2WB to start mayhemduck. So to get more info on what is passed to execvp() that would make execvp() fail and trigger this error message, we would have to put debug print statements in UCI2WB, not in XBoard.

I was thrown off track because this is exactly the same error message as you got with Fairy-Max, which did not involve UCI2WB at all. So in that case it must have been XBoard that was responsible.

So to shed more light on matters you would have to put the printf statements I mentioned (actually only the first two) just before the execvp() line in uci2wb.c, and rebuild UCI2WB.

Which of the two uci2wb would be executed on your system depends on the order in which the directories are specified in the search path. You can figure that out by giving the command

echo $PATH

It could very well be that the difference between distros is caused by one of the two uci2wb being faulty, and that one distro picks the one, and the other distro the other to execute. If you do 'sudo make install' on UCI2WB it should put the resulting binary in /usr/local/bin.

[rgrosz789]

To avoid confusion, I edited xboard-helper.sh so it would copy uci2wb to /usr/local/bin. I also deleted the extra copy located in /usr/games.

I added the debug lines to uci2wb, but it made no difference in xboard.debug <confused>

locale = en_US.UTF-8
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
shuffleOpenings = 0
shuffleOpenings = 0
Version: xboard 4.9.1 + uci2wb ()
Reset(1, 0) from gameMode 0
recognized 'duck' (-1) as variant duck
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") uci2wb debug mayhemduck
390 >first : xboard
protover 2
393 <first : # queue 'protover', searching=0
393 <first : # command protover
394 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
394 >first : accepted setboard
394 >first : accepted usermove
394 >first : accepted debug
394 >first : accepted ping
394 >first : accepted name
394 >first : accepted reuse
394 >first : accepted exclude
394 >first : accepted pause
394 >first : accepted sigint
394 >first : accepted sigterm
394 >first : accepted done
394 <first : feature option="UCI2WB debug output -check 1"
394 >first : accepted option
394 <first : feature option="ponder always -check 0"
394 >first : accepted option
394 <first : # uci
404 <first : # engine said: /usr/games/mayhemduck: 1: Syntax error: "(" unexpected
404 <first : tellusererror UCI2WB: mayhemduck died on me
GameEnds(30, xboard exit, 2)

[hgm]

The output of the printf statements in uci2wb should have appeared in the xboard.debug file in "engine said:" lines. That they don't proves that you are not running the uci2wb that resulted from compiling and installing this, but some other, (probably defective) uci2wb binary.

Try compiling the modified uci2wb just by the command 'make' (so no install), and then in the same directory give the command

xboard -fcp "./uci2wb debug mayhemduck" -debug -variant duck

The ./ before uci2wb should force the use of the uci2wb you just created in the current directory.

[rgrosz789]

I did as you instructed, but there is still no difference in xboard.debug:

locale = en_US.UTF-8
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
shuffleOpenings = 0
shuffleOpenings = 0
Version: xboard 4.9.1 + uci2wb ()
Reset(1, 0) from gameMode 0
recognized 'duck' (-1) as variant duck
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") ./uci2wb debug mayhemduck
408 >first : xboard
protover 2
410 <first : # queue 'protover', searching=0
410 <first : # command protover
410 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
410 >first : accepted setboard
410 >first : accepted usermove
410 >first : accepted debug
410 >first : accepted ping
410 >first : accepted name
410 >first : accepted reuse
410 >first : accepted exclude
410 >first : accepted pause
410 >first : accepted sigint
410 >first : accepted sigterm
410 >first : accepted done
410 <first : feature option="UCI2WB debug output -check 1"
410 >first : accepted option
410 <first : feature option="ponder always -check 0"
410 >first : accepted option
410 <first : # uci
424 <first : # engine said: /usr/games/mayhemduck: 1: Syntax error: "(" unexpected
425 <first : tellusererror UCI2WB: mayhemduck died on me
GameEnds(30, xboard exit, 2)

[JohnWoe]

MayhemDuck doesn't send "Syntax error: "(" unexpected". It only complains about bad moves.
I don't have such errors. Running Linux Mint 21.1 Vera. Sometimes it (Xboard) crashes but when it works, it works well.
Did fast grep on xboard and uci2wb. And couldn't find anything...

Anyway released MayhemDuck 2.3. Should be much better.

[hgm]

This is getting stranger and stranger. Somehow we must be doing something that is different from what we think we are doing. Because nothing we do seems to have any effect whatsoever.

What happens when we totally sabotage uci2wb, by putting as first thing in main (on line 761 above):

printf("goodbye\n"); exit(1);

and repeat what we did above?