Can it be a "real" hash collision

[xr_a_y]

In the currently running D9 tourney, Weini lost a game against GopherCheck in an even position playing a very very stupid move. The game was quite ok (https://lichess.org/iCoTzK5u) but in this position

[d] 4k3/1R6/6p1/Bp3p1p/4pP1P/4P3/b5PK/1r6 w - - 8 51

Weini played Rxb5??.

Can it be a "real" hash collision where the full zhash are equal AND the move is playable ?

Of course I cannot reproduce the issue. On this position, Weini is playing b7b8+ at all depth (I stop searching at depth 23, with a draw score).

I also suspect something about 3 reps draws but I don't know why it would happen specificaly in this game and not others ...

[AlvaroBegue]

That looks like a bug. Something I used to do in my engine Ruy-López is clearing up the search state (hash, killers, history-heuristic tables...) after every move, so I could reproduce everything it did exactly (except for maybe time control). It may make you lose ~30 Elo, but it will let you find bugs potentially worth 100s of Elo.

[sandermvdb]

If you use a 64 bit hashkey (and verify it), a real has collision is very very rare I think. My engine for instance does not verify if the tt move is actually playable, I just assume that it is.

[Ras]

I had a strange occasional bug where stalemate detection and pruning could collide, and that lead to losses exactly like this one here.

The basic flow was like this:

* try very stupid move
* find that it was so stupid that everything below it would be pruned away
* at the end of the for-loop over the moves, see that no move has been tried
* examine "not in check"
* conclude it's a stalemate
* return draw score

In your case, this perhaps might happen in negamax.cpp if "validMoveFound" doesn't get set because everything is pruned. That could also depend on TT contents so it could be hard to nail down.

My solution was to also count legal, but pruned moves and only enter the checkmate/stalemate logic if both the counts for tried AND pruned legal moves were 0.

[Ronald]

I had the same problem a few months ago with Rofchade while changing my searchroot routine, the reason why could be different in your engine however...

In Rofchade I noticed after a while that the strange moves happened after the search reached panic time and the search had to be aborted. If that happens all search info created after the last fully searched move must be ignored, because that info is invalid. I thought I did that correctly but there was one point I had forgotten to exclude the info. So as soon as the search is stopped due to reaching panic time (or other cases, for instance when multi threading) nothing must be written to the hashtable etc., or you could end up with very strange info in it.

[xr_a_y]

Thank you all. I now have some ideas for this bug hunting.

[xr_a_y]

That looks like a bug. Something I used to do in my engine Ruy-López is clearing up the search state (hash, killers, history-heuristic tables...) after every move, so I could reproduce everything it did exactly (except for maybe time control). It may make you lose ~30 Elo, but it will let you find bugs potentially worth 100s of Elo.

I do that also (resetting everything), but I use random initialization for my zobrish key (that is fairly stupid ...), I am going to use a permanent seed for that soon !

[xr_a_y]

If you use a 64 bit hashkey (and verify it), a real has collision is very very rare I think. My engine for instance does not verify if the tt move is actually playable, I just assume that it is.

Yes the hash are verified, 64 bits, and the TT is verified also (is valid). So you are right, this is probably not a hash issue.

[xr_a_y]

In your case, this perhaps might happen in negamax.cpp if "validMoveFound" doesn't get set because everything is pruned. That could also depend on TT contents so it could be hard to nail down.

My solution was to also count legal, but pruned moves and only enter the checkmate/stalemate logic if both the counts for tried AND pruned legal moves were 0.

In Weini pvs search, pruning is done only if a validMoveFound has already been set. So if it is still false at the end of the loop, there was indeed no valid moves.

But i'll check that twice ... thanks

[xr_a_y]

I had the same problem a few months ago with Rofchade while changing my searchroot routine, the reason why could be different in your engine however...

In Rofchade I noticed after a while that the strange moves happened after the search reached panic time and the search had to be aborted. If that happens all search info created after the last fully searched move must be ignored, because that info is invalid. I thought I did that correctly but there was one point I had forgotten to exclude the info. So as soon as the search is stopped due to reaching panic time (or other cases, for instance when multi threading) nothing must be written to the hashtable etc., or you could end up with very strange info in it.

Indeed, nothing is added to TT is stopFlag is set. But recently we discuss in the forum that it is maybe worth using the partially searched root move.