Possible "real" hash collision

[xr_a_y]

I recall that one thing I tried when I was having a similar problem (or, at least, I suspected there was something wrong with repetition detection), was not saving positions to the TT that were given a draw score due to repetition. I think it pointed me in the right direction, but it was so long ago that I can't remember what the problem was.

I think I tried in Weini to not use draw score from TT for the same purpose ... I'll try that tomorrow, thanks

[Joost Buijs]

It could be a lack of king safety. Black is 2 pawns behind, if the engine doesn't understand the threats towards the white king it could just be happy with a draw by repetition from blacks point of view. This is only a suggestion, if you really want to know what is going on you have to analyze the position step by step, and take a look at the static evaluation for all the relevant variations.

[jdart]

It is well known that you must not rely on the hash table for anything that is dangerous if inaccurate. For example I used to retrieve check status (is side to move in check?). But in case of a collision, getting this wrong could cause a crash. That said, there are many other possible causes of crash bugs. Running under Valgrind or similar tools is a good way to find issues.

[xr_a_y]

It is well known that you must not rely on the hash table for anything that is dangerous if inaccurate. For example I used to retrieve check status (is side to move in check?). But in case of a collision, getting this wrong could cause a crash. That said, there are many other possible causes of crash bugs. Running under Valgrind or similar tools is a good way to find issues.

Indeed Jon, but we are not looking for a crash thing here, only a blunder.
In fact a somehow deep blunder because of delaying checks ; not directly liked to TT usage, nor pruning. Probably something just about draw management.

I like the idea given before that a better king attack score (or rook on 7th rank) would have help Minic to not fall in the bad move.

[brianr]

It might not be an issue in this case, but something that many engines (including Tinker) are surprisingly sensitive to is how to handle repetitions. I have found that the full 3-reps test should be used at the root, but anywhere in the search to score the 2nd rep as a draw and not to wait for the 3rd. I also have tried to count consecutive checks in a fruitless effort to detect perpetuals, but it never seemed to help and occasionally hurt, so it is not used.

[xr_a_y]

It might not be an issue in this case, but something that many engines (including Tinker) are surprisingly sensitive to is how to handle repetitions. I have found that the full 3-reps test should be used at the root, but anywhere in the search to score the 2nd rep as a draw and not to wait for the 3rd. I also have tried to count consecutive checks in a fruitless effort to detect perpetuals, but it never seemed to help and occasionally hurt, so it is not used.

I test for 3 reps at pvnode (and root) and 1 rep everywhere else. I think it was a HGM advice to test only 1 rep when I was struggling with Weini.

[brianr]

Maybe just try not testing for 3 on PV nodes, only at the root.

[xr_a_y]

Ok, using TT in qsearch solve the issue ... and gives +50elo ... don't really know why ... side effect maybe