Problem integrating Crafty with Windows GUI

[ignacioalex]

Hi all,

I'm developing an open source Java GUI application to play chess and I'm trying to integrate it with Crafty 23.0. Crafty's executable is started as an external subprocess, and communication is handled through the standard input/output console by using the Winboard 2 protocol.

So far everything seems to be working on Linux. However on Windows Crafty strangely complains about some illegal moves which are in fact legal. Some examples are (Crafty is playing black):

1. e4 d5 2. exd5 (illegal move exd5?)
1. e4 c6 2. d4 d5 3. exd5 (illegal move exd5?)
1. e4 e5 2. Nf3 d6 3. d4 Nf6 4. dxe5 Nxe4 5. exd6 (illegal move exd6?)

Typically the last lines in Crafty's log file are:

White(2): exd5
Illegal move: exd5

It appears that Crafty has correctly received the input move from the GUI, but something wrong is going on in the C code and it was interpreted as an illegal move.

Curiously I do not have any problems when using Crafty directly from the command line (cmd.exe); this only happens when I'm talking to Crafty from my GUI application.

I compiled a Crafty executable using the GCC toolchain with the Eclipse/CDT IDE and tried to attach the debugger to Crafty's external process, but gdb crashes and a Windows dialog box pops up saying that crafty.exe has performed an illegal operation and needs to be shut down.

If anyone could offer to help with debugging Crafty using a different Windows toolchain I would be glad to post a binary executable of my GUI application.

Other things I've tried without success:

- Explicitly setting the communication stream encoding to ASCII, UTF-8 or ISO 8859-1.
- Sending the move as e4xd5, e4d5 or Pxd5.
- Turning off Winboard protocol's san feature: Crafty complains with an error message.

Any idea or suggestion is greatly appreciated!

Alex

[Gian-Carlo Pascutto]

Post the crafty logfile.

[hgm]

Code: Select all

Crafty v23.0 (1 cpus)

White(1): skill 50
skill level set to 50%
White(1): xboard
White(1): protover 2
feature ping=1 setboard=1 san=1 time=1 draw=1
feature sigint=0 sigterm=0 reuse=1 analyze=1
feature myname="Crafty-23.0" name=1
feature playother=1 colors=0
feature variants="normal,nocastle"
feature done=1
White(1): accepted ping
White(1): accepted setboard
White(1): accepted san
White(1): accepted time
White(1): accepted draw
White(1): accepted sigint
White(1): accepted sigterm
White(1): accepted reuse
White(1): accepted analyze
White(1): accepted myname
White(1): accepted name
White(1): accepted playother
White(1): accepted colors
White(1): accepted variants
White(1): accepted done
White(1): hard
pondering enabled.
White(1): level 0 5 0
game/300 seconds primary time control
White(1): new
White(1): e4
time used: 4.14
book moves {e5, c5, c6, d5}
book 0.0s 1% d5! Nc3
Black(1): d5
time used: 0.00
White(2): Nc3 [pondering]
book moves {c6, d4, dxe4, Nf6}
book 0.0s 17% Nf6 e5
White(2): exd5
Illegal move: exd5

[bob]

Code: Select all

Crafty v23.0 (1 cpus)

White(1): skill 50
skill level set to 50%
White(1): xboard
White(1): protover 2
feature ping=1 setboard=1 san=1 time=1 draw=1
feature sigint=0 sigterm=0 reuse=1 analyze=1
feature myname="Crafty-23.0" name=1
feature playother=1 colors=0
feature variants="normal,nocastle"
feature done=1
White(1): accepted ping
White(1): accepted setboard
White(1): accepted san
White(1): accepted time
White(1): accepted draw
White(1): accepted sigint
White(1): accepted sigterm
White(1): accepted reuse
White(1): accepted analyze
White(1): accepted myname
White(1): accepted name
White(1): accepted playother
White(1): accepted colors
White(1): accepted variants
White(1): accepted done
White(1): hard
pondering enabled.
White(1): level 0 5 0
game/300 seconds primary time control
White(1): new
White(1): e4
time used: 4.14
book moves {e5, c5, c6, d5}
book 0.0s 1% d5! Nc3
Black(1): d5
time used: 0.00
White(2): Nc3 [pondering]
book moves {c6, d4, dxe4, Nf6}
book 0.0s 17% Nf6 e5
White(2): exd5
Illegal move: exd5

How was this produced? No way I can reproduce that here. I tried everything I could think of. All I can guess is that the compiler somehow broke something for the version being used. I've never heard of such a bug actually showing up in a released version of Crafty, they are tested beyond thorough both on my cluster and on ICC.

[ignacioalex]

This problem is not specific to Crafty 23.0: I've also tried version 20.14 from Hyatt's ftp site with the same results. I've also tried different executables I found over the web before compiling my own from source.

What's puzzling is that I do not get any strange behaviour when using Crafty directly from the console, which is indicative that the problem lies in my Java application. On the other hand Crafty's log file seems to indicate that it received the input correctly. I also have no idea why it works on Linux.

As I said before, I can post a binary of my application (or even the Java source) somewhere if someone wants to aid in the investigation.

[bob]

This problem is not specific to Crafty 23.0: I've also tried version 20.14 from Hyatt's ftp site with the same results. I've also tried different executables I found over the web before compiling my own from source.

What's puzzling is that I do not get any strange behaviour when using Crafty directly from the console, which is indicative that the problem lies in my Java application. On the other hand Crafty's log file seems to indicate that it received the input correctly. I also have no idea why it works on Linux.

As I said before, I can post a binary of my application (or even the Java source) somewhere if someone wants to aid in the investigation.

One question: Is there any chance that you are somehow sending an unprintable character either on the front of the move, or on the end of the move? That would break the parsing outright, but the error would be confusing since the character in question will not print and you won't see it.

For a test, you could try just sending a blank line before you send the move, and a blank line after you send the move, That would take the bad character to a line by itself unless it is actually embedded in the move string itself.

You could also modify Crafty's source and display the move character by character in hex to see if there is an odd character included. That would be my guess...

[hgm]

Funny: that is exactly the same thing as I suggested on WB forum, where this problem was also posted. Of course if a problem occurs on Windows and not in Linux, '\r' suggests itself. But likely Crafty can stand that, because it is so common.

[bob]

Funny: that is exactly the same thing as I suggested on WB forum, where this problem was also posted. Of course if a problem occurs on Windows and not in Linux, '\r' suggests itself. But likely Crafty can stand that, because it is so common.

I am not sure, in fact. I do a simple read() to read in the move, and I do not have any special parsing to deal with either \r that I notice, although \n is removed if it might be a problem. However, it would seem to me that he would have to intentionally add a \r character when sending a move, although I am not sure just what Java is doing there...

[ignacioalex]

Hi all,

Good news: following a long workout period I finally discovered the problem! After an easy fix I'm now capable of playing against Crafty with my Windows GUI too.

There was an issue with the C code that was unrelated to the parsing of the moves. In order to verify that the input move is legal Crafty generates all possible legal moves in the position and tries to match the input move against any of them. The code that generates all legal moves (in particular, pawn capture moves) was not working fine because it was using a data structure that was corrupt in memory. So in our test case:

1. e4 d5 2. exd5

The exd5 move was not being generated, and so it was interpreted as an illegal move.

How did the key data structure got corrupt in memory? That was because my Java application was setting a very long path to the directory where Crafty outputs its log files, and the variable that stores this path was a char[64] array. So anything beyond this limit was corrupting other areas in memory. The fix was to simply change it to a char[255] array.

Maybe this problem didn't show up in the Linux GUI because the compiler lays out the variables in memory differently, and that would cause other sorts of problems later.

To reproduce the problem starting Crafty directly from the console all is necessary is changing the logpath in crafty.rc:
logpath=C:\runtime-com.haundrix.games.product\.metadata\.plugins\com.haundrix.games\crafty

The fix is changing the following lines in data.h:
extern char log_filename[255];
extern char history_filename[255];
and in data.c:
char log_filename[255];
char history_filename[255];

I don't know if it's documented somewhere that the logpath can't be longer than 64 characters, but an even better fix would be checking against this limit in code that writes the logpath and then throw an exception right away.
In my case the problem was occurring at the following lines in init.c:
sprintf(log_filename, "%s/log.%03d", log_path, log_id);
sprintf(history_filename, "%s/game.%03d", log_path, log_id);

I feel much better now that I'll let my users have some fun with Crafty!

[bob]

Hi all,

Good news: following a long workout period I finally discovered the problem! After an easy fix I'm now capable of playing against Crafty with my Windows GUI too.

There was an issue with the C code that was unrelated to the parsing of the moves. In order to verify that the input move is legal Crafty generates all possible legal moves in the position and tries to match the input move against any of them. The code that generates all legal moves (in particular, pawn capture moves) was not working fine because it was using a data structure that was corrupt in memory. So in our test case:

1. e4 d5 2. exd5

The exd5 move was not being generated, and so it was interpreted as an illegal move.

How did the key data structure got corrupt in memory? That was because my Java application was setting a very long path to the directory where Crafty outputs its log files, and the variable that stores this path was a char[64] array. So anything beyond this limit was corrupting other areas in memory. The fix was to simply change it to a char[255] array.

Maybe this problem didn't show up in the Linux GUI because the compiler lays out the variables in memory differently, and that would cause other sorts of problems later.

To reproduce the problem starting Crafty directly from the console all is necessary is changing the logpath in crafty.rc:
logpath=C:\runtime-com.haundrix.games.product\.metadata\.plugins\com.haundrix.games\crafty

The fix is changing the following lines in data.h:
extern char log_filename[255];
extern char history_filename[255];
and in data.c:
char log_filename[255];
char history_filename[255];

I don't know if it's documented somewhere that the logpath can't be longer than 64 characters, but an even better fix would be checking against this limit in code that writes the logpath and then throw an exception right away.
In my case the problem was occurring at the following lines in init.c:
sprintf(log_filename, "%s/log.%03d", log_path, log_id);
sprintf(history_filename, "%s/game.%03d", log_path, log_id);

I feel much better now that I'll let my users have some fun with Crafty!

Made the change in crafty's source. I think the main problem is that _most_ of us do not use paths that are that long.