v5.0.0 illegal move about clarity

[Vast342]

Do you have any more information? logs or something like that? Trying that position locally it simply alternates between finding mate in 5-8 moves.

[tissatussa]

Do you have any more information?

i compiled your v5.0.0 source on Linux Xubuntu 22.04.
i set 128 Mb Hash and 2 threads.
look at the moves it played after taking the last White piece (Rook) by 85...Rxb1 :
8/8/4K3/8/8/8/2k5/1r6 w - - 0 86
from here, Clarity v5.0.0 doesn't seem to have a clear mating plan .. according to SF 16 it's mate-in-15 in that position, so with optimal play the game should have ended on move 100 at max .. my feeling is that its logic gets 'confused' when so less pieces are left on the board .. in general it never had any error or illegal move ..

logs or something like that?

no log preserved .. i used CuteChess, a log output contains just the UCI strings by the engines .. when CuteChess gets 'best move a1a1' it shows the message "makes an illegal move: a1a1", there's no crash, CuteChess just decides to end the game (and conclude a draw in this case) .. maybe when i start CuteChess in terminal (which i didn't) i could have seen more info lines, error outputs (non-UCI-string) by Clarity .. i had such experience with other engines (in other cases). Pitty..

Trying that position locally it simply alternates between finding mate in 5-8 moves.

sure .. this bug (?) will be hard to trace ..

[Vast342]

The move history in the screenshot you sent and in the pgn you sent suggests that something happened a few moves earlier that may have caused it to get stuck, since it says it searched to a depth of 4 and was saying a draw.

[Vast342]

My current theory is that something happened after move 100 that led to an improper search being performed, and from there a few depth later it ran out of moves in the Transposition Table and then outputted the null move (a1a1 is how I store null moves internally)

[tissatussa]

good thinking i guess .. i encounter sometimes other engines output 'a1a1' also - will be same coding .. yes, that TT / Hash can be buggy, and hard to detect / prove .. it happens AFTER many moves, then the TT might get corrupted ? HTH

[Vast342]

What is your CPU / How many nodes per second were the 2 engines getting during the game above? I'm considering trying to recreate this game locally with the 2 engines but I'm not sure if it would be similar enough.

[Vast342]

I'm also not sure if I can obtain Winter 2.04b

[tissatussa]

..I'm also not sure if I can obtain Winter 2.04b..

i think that's beyond the problem .. it could have been any other engine, it can happen after 85 moves or so, with a full (?) TT with some incorrect logic. In the meantime i may do more matches to see if such error ever happens again .. not sure .. could you think of rewriting some part of the TT logic ? i have no clue ..

How many nodes per second were the 2 engines getting during the game above?

sorry, i didn't mention .. i didn't expect it to happen either ..

$ neofetch

           `-/osyhddddhyso/-`              roelof@roelof-HP-Elite-x2-1012-G2 
        .+yddddddddddddddddddy+.           --------------------------------- 
      :yddddddddddddddddddddddddy:         OS: Xubuntu 22.04.2 LTS x86_64 
    -yddddddddddddddddddddhdddddddy-       Host: HP Elite x2 1012 G2 
   odddddddddddyshdddddddh`dddd+ydddo      Kernel: 5.15.0-71-generic 
 `yddddddhshdd-   ydddddd+`ddh.:dddddy`    Uptime: 4 days, 2 hours, 1 min 
 sddddddy   /d.   :dddddd-:dy`-ddddddds    Packages: 3064 (dpkg), 15 (snap) 
:ddddddds    /+   .dddddd`yy`:ddddddddd:   Shell: bash 5.1.16 
sdddddddd`    .    .-:/+ssdyodddddddddds   Resolution: 1920x1080, 1920x1080 
ddddddddy                  `:ohddddddddd   DE: Xfce 4.16 
dddddddd.                      +dddddddd   WM: Xfwm4 
sddddddy                        ydddddds   WM Theme: Default 
:dddddd+                      .oddddddd:   Theme: Greybird [GTK2/3] 
 sdddddo                   ./ydddddddds    Icons: elementary-xfce-darker [GTK2/3] 
 `yddddd.              `:ohddddddddddy`    Terminal: xfce4-terminal 
   oddddh/`      `.:+shdddddddddddddo      Terminal Font: DejaVu Sans Mono 9 
    -ydddddhyssyhdddddddddddddddddy-       CPU: Intel i5-7200U (4) @ 3.100GHz 
      :yddddddddddddddddddddddddy:         GPU: Intel HD Graphics 620 
        .+yddddddddddddddddddy+.           Memory: 5651MiB / 7828MiB 
           `-/osyhddddhyso/-`
                                                                   

[Vast342]

I have a few instances of this issue occurring in the past, however I had assumed they were due to my CPU being fully utilised at the time since they were all coincidentally while I was compiling. That does not seem to be the case though. As of now I am unable to reproduce the error, nor do I have any idea what is causing it yet.

[Vast342]

When playing through your example game and the ones I have on record, Clarity doesn't seem to agree with most of the moves played there, nor did it agree with the scores. This has led me to believe that some part of it is a remnant of a previous game. Through that, I noticed that one of my history tables wasn't getting cleared properly in between games. Thank you for bringing this issue to my attention.

[Vast342]

I have now made the fixing branch and committed my 2 fix ideas, and I am going to leave a test of that branch against itself running overnight to see if there are any illegal moves. If there are none by the time 10000 games have been completed, I am going to deem this issue as fixed until there is evidence otherwise.

[tissatussa]

..This has led me to believe that some part of it is a remnant of a previous game..

that's also my feeling .. as i stated : yes, that TT / Hash can be buggy, and hard to detect / prove .. it happens AFTER many moves, then the TT might get corrupted ? In the meantime i let Clarity v5.0.0 play a few more games (15min+3bonus) against several engines and i had no troubles of any kind so far ..

[tissatussa]

..Through that, I noticed that one of my history tables wasn't getting cleared properly in between games..

yes, such things .. good luck finding the bug !

[Vast342]

In the meantime i let Clarity v5.0.0 play a few more games (15min+3bonus) against several engines and i had no troubles of any kind so far ..

yeah, as always these bugs happen very few times and with a lot of time in between them.

as of right now the test is at 8944 games out of 10000 and there have yet to be illegal moves.

[Vast342]

One of my fixes is a backup in case a null move gets returned by the engine, however since it's just a covering up of the problem and not a fix to the problem itself, I am going to do another 10000 game test without it just to make sure that the issue has been fixed fully.

[tissatussa]

..Through that, I noticed that one of my history tables wasn't getting cleared properly in between games..

so you did correct a code part ? or maybe you found a severe flaw ?

[Vast342]

I have corrected that, as well as adding a limiter to a feature that is known to cause search size explosions.

[Vast342]

Both 10000 game tests have finished with no illegal moves, therefore I am deeming that these issues are fixed until I discover evidence otherwise.

[Vast342]

The actual cause of this issue has now been found, and it appears to be that the GUI gave Clarity a negative amount of time to search, and as such Clarity just returned a null move after doing no search at all. I can now confirm that that has been fixed.

[tissatussa]

..the GUI gave Clarity a negative amount of time to search..

that's weird !
how did you found out ? You must have been thinking out-of-the-box, i'd never thought about this .. as you'd noticed, i gave 3 seconds bonus time, but how could time be negative ? Is this a bug in (the GUI of) CuteChess ?