Duck Chess

[rgrosz789]

Okay that gave the expected results!

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
808 >first : xboard
protover 2
810 <first : goodbye

[hgm]

OK, so at least what we do with the uci2wb source does propagate to the xboard.debug file. Perhaps the problem is that the execvp partly works, and somehow prevents flushing of the output buffer. So go back to the previous version with the two printf, and between those and the execvp() put

fflush(stdout);

Then the output of the printf must appear in the xboard.debug.

[rgrosz789]

Here's the xboard.debug ouput:

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
423 >first : xboard
protover 2
435 <first : # queue 'protover', searching=0
435 <first : # command protover
435 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
435 >first : accepted setboard
435 >first : accepted usermove
435 >first : accepted debug
435 >first : accepted ping
435 >first : accepted name
435 >first : accepted reuse
435 >first : accepted exclude
435 >first : accepted pause
435 >first : accepted sigint
435 >first : accepted sigterm
435 >first : accepted done
435 <first : feature option="UCI2WB debug output -check 1"
435 >first : accepted option
435 <first : feature option="ponder always -check 0"
435 >first : accepted option
435 <first : # uci
435 <first : # engine said: a: {mayhemduck}
453 <first : # engine said: /usr/games/mayhemduck: 1: Syntax error: "(" unexpected
453 <first : tellusererror UCI2WB: mayhemduck died on me
GameEnds(30, xboard exit, 2)

[hgm]

Well, at least the debug printing of the first word of the engine command now appears in the engine output log. And it is what it should be.

The second printf doesn't seem to do anything, though. Now argv[1] should be a null pointer, because there aren't supposed to be any additional arguments to 'mayhemduck'. Perhaps this upsets the version of printf in this distro, although often this would then just print '(null)' in place of the string.

So far I have assumed the mysterious error message is from the perror() in UCI2WB after the execvp fails. But this has not unambiguously proven, though. So let's change the code we are examining (the debug printf up to and including the execvp() to:

printf("a: {%s}\n", argv[0]);
printf("b: {%llx}\n", argv[1]);
fflush(stdout);

execvp(argv[0], argv);

printf("c: execvp failed\n");
fflush(stdout);

This should unambiguously show us that the error message is indeed originating from UCI2WB, and not from mayhemduck.

[rgrosz789]

Here's the latest 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
391 >first : xboard
protover 2
393 <first : # queue 'protover', searching=0
393 <first : # command protover
393 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
393 >first : accepted setboard
393 >first : accepted usermove
393 >first : accepted debug
393 >first : accepted ping
393 >first : accepted name
393 >first : accepted reuse
393 >first : accepted exclude
393 >first : accepted pause
393 >first : accepted sigint
393 >first : accepted sigterm
393 >first : accepted done
393 <first : feature option="UCI2WB debug output -check 1"
393 >first : accepted option
393 <first : feature option="ponder always -check 0"
393 >first : accepted option
393 <first : # uci
393 <first : # engine said: a: {mayhemduck}
393 <first : # engine said: b: {0}
397 <first : # engine said: /usr/games/mayhemduck: 1: Syntax error: "(" unexpected
397 <first : tellusererror UCI2WB: mayhemduck died on me
GameEnds(30, xboard exit, 2)

[hgm]

That is interesting. It never gets beyond the execvp() call. The printf a and b show that the argv argument to execvp() is what is should be: a null-terminated list with a single element, the name of the file to execute. But there never appears any output from the third printf. Which also proves the Syntax error message is not from the perror(0 call that follows it. (To make this absolutely sure, we could delete that perror().)

So it seems the execvp() succeeds, and hence runs mahemduck, which apparently emits the error message. What happens when you type on the command line:

mayhemduck
uci

?

[rgrosz789]

It appears that I simply can't run mayhemduck - and mayhem81 (non-duck) shows the same behavior:

[hgm]

It seems this is purely an engine problem. Although it is a bit strange that the third printf was not visible in the debug file. If the format of the mayhemduck file violates the rules for executables, I would expect execvp() to return with an error code, and the following perror() to print the corresponding message. But the behavior is like the system itself prints the message, and then terminates the process, without ever returning from the execvp() call.

I am still curious whether that error message disappears when you delete the perror() call. (And leave in all the printf.)

[rgrosz789]

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.

It appears that I must compile mayhem (non-duck) from source to run it on my old PC. I tried several of the linux executables from your repository, with no success:

[hgm]

I am still puzzled that at one point you also got this error message with Fairy-Max, which threw me completely off track. While later you reported the problem had disappeared.

Could this have been the same issue? That you had the problem when running Fairy-Max from a downloaded binary not compatible with your CPU, and then later had compiled it yourself?