Winboard Forum

in the xboard debug file, I see all the pings but none of the pongs despite my engine is sending them. Is this a normal behavior?

Miguel
a small fragment of the debug file

1773 >first : ping 1
Reset(1, 1) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
8707 >first : force
8707 >first : ping 2
shuffleOpenings = 0
TC string = '+40/5'
mps=40 tc=300000 inc=0
TC string = '+40/5'
mps=40 tc=300000 inc=0
8709 >first : memory 68
8709 >first : egtbpath gaviota /media/bigdisk/experiment
8709 >first : cores 2
8709 >first : new
random
8709 >first : level 40 5 0
8709 >first : post
8709 >first : hard
8709 >first : ping 3
GameEnds(40, xboard exit, 2)
13285 >first : result * {xboard exit}
13286 >first : force
13286 >first : ping 4
13286 >first : quit

What setting of -engineDebugOutput do you use?

I see that I forgot to recognize pong when deciding if output is protocol-violating. So if you exclude protocol-violating output from the debug file with -engineDeebugOutput 0 this would explain why pongs are killed. Definitely a bug, of course.

Code: Select all

   if(appData.engineComments != 1) { /* [HGM] debug: decide if protocol-violating output is written */
      char start = message[0];
      if(start >='A' && start <= 'Z') start += 'a' - 'A'; // be tolerant to capitalizing
      if(sscanf(message, "%d%c%d%d%d", &i, &c, &i, &i, &i) != 5 &&
         sscanf(message, "move %c", &c)!=1  && sscanf(message, "offer%c", &c)!=1 &&
         sscanf(message, "resign%c", &c)!=1 && sscanf(message, "feature %c", &c)!=1 &&
         sscanf(message, "error %c", &c)!=1 && sscanf(message, "illegal %c", &c)!=1 &&
         sscanf(message, "tell%c", &c)!=1   && sscanf(message, "0-1 %c", &c)!=1 &&
         sscanf(message, "1-0 %c", &c)!=1   && sscanf(message, "1/2-1/2 %c", &c)!=1 && start != '#')
         { quote = "# "; print = (appData.engineComments == 2); }
      message[0] = start; // restore original message
   }


H.G.Muller wrote:What setting of -engineDebugOutput do you use?

I see that I forgot to recognize pong when deciding if output is protocol-violating. So if you exclude protocol-violating output from the debug file with -engineDeebugOutput 0 this would explain why pongs are killed. Definitely a bug, of course.

Code: Select all

   if(appData.engineComments != 1) { /* [HGM] debug: decide if protocol-violating output is written */
      char start = message[0];
      if(start >='A' && start <= 'Z') start += 'a' - 'A'; // be tolerant to capitalizing
      if(sscanf(message, "%d%c%d%d%d", &i, &c, &i, &i, &i) != 5 &&
         sscanf(message, "move %c", &c)!=1  && sscanf(message, "offer%c", &c)!=1 &&
         sscanf(message, "resign%c", &c)!=1 && sscanf(message, "feature %c", &c)!=1 &&
         sscanf(message, "error %c", &c)!=1 && sscanf(message, "illegal %c", &c)!=1 &&
         sscanf(message, "tell%c", &c)!=1   && sscanf(message, "0-1 %c", &c)!=1 &&
         sscanf(message, "1-0 %c", &c)!=1   && sscanf(message, "1/2-1/2 %c", &c)!=1 && start != '#')
         { quote = "# "; print = (appData.engineComments == 2); }
      message[0] = start; // restore original message
   }


H.G.Muller wrote:engineDeebugOutput

I used the default, which is 0, apparently. If I use 2, I get this:

1803 >first : level 40 5 0
1803 >first : post
1803 >first : hard
1803 >first : ping 1
1804 <first : # allocate 68 Mb
1804 <first : # error {unknown command}: egtbpath
1852 <first : # pong 1

So you are right about it.

Miguel

That is still another bug then: the default is supposed to be 1. (Which would cause the old behavior, which is to write everything the engine cares to dump into the debug file.) This is of course the mode one should work in when debugging an engine.

Mode 0 was provided to make it possible to protect debug-file using programs from non-compliant engine output that might crash them. Mode 2 was provided to have the best of both worlds with somewhat smarter debug-file using programs, which can stand anything that starts with # (by ignoring that line, as WinBoard would when the engine had pre-fixed it with #).

I don't understand how XBoard could have 0 as default, though. The option is declared as this:

Code: Select all

    { "engineDebugOutput", "engineDebugOutput", XtRInt,
   sizeof(int), XtOffset(AppDataPtr, engineComments),
   XtRImmediate, (XtPointer) 1},


I was under the impression that the last parameter in the struct was the default value.

It is fishy that the error {...} message sent by your engine is commented out like it is non-compliant. It seems to me that this is one of the cases that should pass the test I posted above.

I guess the fact that this message is sent points to another bug (the most horrible of all): apparently XBoard sends egtbpath, no doubt in stead of egtpath, which it should have sent according to the specs. Sh±t! After some discussion we changed this command from egtbpath to egtpath (because bitbases were no egtbs), and I changed the string in the source, but I see now that it actually occurred twice. Once when a match was found with the Winboard_x defaultPathEGTB parameter, but in another place after a match with the new egtFormats option...

H.G.Muller wrote:That is still another bug then: the default is supposed to be 1. (Which would cause the old behavior, which is to write everything the engine cares to dump into the debug file.) This is of course the mode one should work in when debugging an engine.

Mode 0 was provided to make it possible to protect debug-file using programs from non-compliant engine output that might crash them. Mode 2 was provided to have the best of both worlds with somewhat smarter debug-file using programs, which can stand anything that starts with # (by ignoring that line, as WinBoard would when the engine had pre-fixed it with #).

I don't understand how XBoard could have 0 as default, though. The option is declared as this:

Code: Select all

    { "engineDebugOutput", "engineDebugOutput", XtRInt,
   sizeof(int), XtOffset(AppDataPtr, engineComments),
   XtRImmediate, (XtPointer) 1},


I was under the impression that the last parameter in the struct was the default value.

It is fishy that the error {...} message sent by your engine is commented out like it is non-compliant. It seems to me that this is one of the cases that should pass the test I posted above.

I guess the fact that this message is sent points to another bug (the most horrible of all): apparently XBoard sends egtbpath, no doubt in stead of egtpath, which it should have sent according to the specs. Sh±t! After some discussion we changed this command from egtbpath to egtpath (because bitbases were no egtbs), and I changed the string in the source, but I see now that it actually occurred twice. Once when a match was found with the Winboard_x defaultPathEGTB parameter, but in another place after a match with the new egtFormats option...

Crap!
I am glad you saw egtbpath. I could have stared to it for hours without understanding what was going on. I am about to continue where I left yesterday and I could have wasted a lot of time. Moving on... now I can waste my time with other things
For now I am going to use egtbpath as a synonym, or maybe I can replace the word in the sources until the next version.

Miguel

It should be easily found in backend.c

I guess this one is so bad that it forces us to do a new release really soon.