Collecting thoughts on a strange bug I cannot reproduce

[AndrewGrant]

I was watching Ethereal play a game in one of Graham's tournaments. When I began watching Ethereal had a +10.00 evaluation, with Greko having a -10.00. Before the game ended I left my computer, and came back to a loss!

I tracked down the PGN and found the position in which the game was lost.

2r5/8/8/5Kpp/8/5P2/3k4/2R5 b - - 0 8



For some reason, my engine chose to make Ke2, when, quite clearly, capturing the white rook with either the black king or black rook, is a much better move.

I tried the position in my engine, and got the expected result. c8c1.

I then tried to use some of the moves before this to build the hash back up. Still c8c1.

I'm not sure what other ways I can reproduce this. Additionally, I don't have a clue what would cause this! Intuition tells me it must be related to the hash table, as that is what is most certainly different between my test and between the actual game.

Does anyone have any ideas as to either the root of the problem, or a means to reproduce it?

[D Sceviour]

I was watching Ethereal play a game in one of Graham's tournaments. When I began watching Ethereal had a +10.00 evaluation, with Greko having a -10.00. Before the game ended I left my computer, and came back to a loss!

I tracked down the PGN and found the position in which the game was lost.

2r5/8/8/5Kpp/8/5P2/3k4/2R5 b - - 0 8



For some reason, my engine chose to make Ke2, when, quite clearly, capturing the white rook with either the black king or black rook, is a much better move.

I tried the position in my engine, and got the expected result. c8c1.

I then tried to use some of the moves before this to build the hash back up. Still c8c1.

I'm not sure what other ways I can reproduce this. Additionally, I don't have a clue what would cause this! Intuition tells me it must be related to the hash table, as that is what is most certainly different between my test and between the actual game.

Does anyone have any ideas as to either the root of the problem, or a means to reproduce it?

There are a lot of different reasons that games and positions cannot be duplicated in console mode when debugging. There are a variety of dimensioning bugs, array errors and phasing that can do this.

* look at changes in game phase that might effect scoring or cutoffs
* look at repetitions based on long move lists
* look at PVS. Turned on/off creates different killers for move ordering and reduction differences. Different killers can create different move orderings.
* look at time out. Was an incomplete hash score saved somewhere after an abort search?

[AndrewGrant]

Hmm... some of that sounds promising, some not so much.

look at time out. Was an incomplete hash score saved somewhere after an abort search?

Don't think this is the answer. Before storing entries I check the current time vs the cut-off time, always

look at changes in game phase that might effect scoring or cutoffs

This sounds like a possibility, but I find it hard to imagine something so drastic as this situation can be the result of phase changes.

look at repetitions based on long move lists

One of my initial thoughts was that maybe, due to very unfortunate position hashing, that capturing the White rook would be seen as a draw, due to a much older duplicated position. However, this would mean that capturing with either the king OR the rook, would have to hash wrong. Very unlikely.

[D Sceviour]

I noticed a potential bug in Ethereal earlier. Specifically, check the Delta prune in Quiescence. It might return alpha, but I think it should return value. That might create an unpredictable error.

Incidentally, Schooner had a similar Rook problem on bugs that cannot be reproduced:
http://talkchess.com/forum/viewtopic.ph ... 35&t=60135

[AndrewGrant]

Hmm... I have ZERO clue why I am returning alpha instead of 'value. I have no memory of paying a great deal of attention to that section of the program. I'll run a test without that, see if I find any ELO gains

[Evert]

I would approach this under the assumption that time ran out while the program was trying to resolve a fail low, which caused a random move to be played. I've had bugs like that, which tend to have the symptoms you describe (as well as being extremely hard to reproduce).

[cdani]

Also if you don't find the cause, maybe you can parse your test games for other loses after having won positions. Maybe some of the games can give you a clue. Someone have a tool to do such parsing? I think this can be useful to much people, for example to detect bad evaluated endgames.

[Guenther]

Also if you don't find the cause, maybe you can parse your test games for other loses after having won positions. Maybe some of the games can give you a clue. Someone have a tool to do such parsing? I think this can be useful to much people, for example to detect bad evaluated endgames.

Such a tool exists since over a decade and it even has a GUI ;-)

http://home.pacific.net.au/~tommyinoz/gameanalyser.html

Note that the description of the tool on the original website is not updated.
(You don't need WB debug files for processing - that ability was just there,
because WB at that time could not save the relevant info into PGN files.
Actually you just need PGN files with the score info included for making it work)

I just checked it again with a recently created PGN file containing the
usual score/depth and times info and it works like a charm.

Guenther

[cdani]

Such a tool exists since over a decade and it even has a GUI

http://home.pacific.net.au/~tommyinoz/gameanalyser.html

Thanks!

[AndrewGrant]

I don't have access to the actual PGN for the game as of now...

I only had the PGN from when I connected to when I left, which started at move #73.... and the move in which I threw the game was around 6-8 moves later.... Very likely that it was the #80th move, making a time issue likely.