Stockfish problem in Scid

[mcostalba]

I can verify this on 32bit Fedora 7. The engine becomes unresponsive after these commands

Code: Select all

Scid  : setoption name Clear Hash value false
Scid  : isready

Thanks for the hint. Patch pushed to github, should be fixed now, please pull from master and retest.

As a side note the command 'setoption name Clear Hash value false' is wrong because 'Clear Hash' is an UCI BUTTON and so the correct way to trigger the corresponding action (that is clearing the hash table) is:

Code: Select all

setoption name Clear Hash

See http://wbec-ridderkerk.nl/html/UCIProtocol.html for reference.

[stevenaaus]

Thanks for the hint. Patch pushed to github, should be fixed now, please pull from master and retest.

Yes - seems fine.

As a side note the command 'setoption name Clear Hash value false' is wrong because 'Clear Hash' is an UCI BUTTON and so the correct way to trigger the corresponding action (that is clearing the hash table) is:

Cheers. I've changed Scid vs. PC to properly handle UCI buttons. The engine remains open when the UCI Options window is launched (too allow for processing of button presses then). And buttons are no longer saved to config file. Hopefully everything is fine, as the change is non-trivial.

[Eelco de Groot]

I can verify this on 32bit Fedora 7. The engine becomes unresponsive after these commands

Code: Select all

Scid  : setoption name Clear Hash value false
Scid  : isready

Thanks for the hint. Patch pushed to github, should be fixed now, please pull from master and retest.

As a side note the command 'setoption name Clear Hash value false' is wrong because 'Clear Hash' is an UCI BUTTON and so the correct way to trigger the corresponding action (that is clearing the hash table) is:

Code: Select all

setoption name Clear Hash

See http://wbec-ridderkerk.nl/html/UCIProtocol.html for reference.

Hello,

Good work guys!

I don't really follow all the details but try to include all the Stockfish changes into Rainbow Serpent as well. My version still crashes at the moment in the console window, with an c0000005 exception that I still have to track down. It is probably some codechange not related to the default Stockfish, and if I use the latest version of search.cpp from Stockfish itself instead of my version I have no crash in the console. However during debugging I got a few asserts that were tripped and one of which I suspected also influences Stockfish a bit.

I am not sure it is going to matter much but it turns out the exception search can, also in Stockfish, return a ss->currentMove that is identical to the ttMove (or to move). There is no ss->bestMove anymore and ss->currentMove is also not used anywhere here I believe, but if as I understand correctly this ss->currentMove is now the result of the exclusion search, it is not really correct, it should never return a searchresult related to ttMove it self. (That is why also nullmove is not used in the exclusion search even if the nullmove search does of course not directly involve the ttMove)

The assert in Stockfish is inserted at this point in the code

Code: Select all

if (   singularExtensionNode
          && !ext
          && move == ttMove
          && pos.pl_move_is_legal(move, ci.pinned))
      {
          Value ttValue = value_from_tt(tte->value(), ss->ply);

          if (abs(ttValue) < VALUE_KNOWN_WIN)
          {
              Value rBeta = ttValue - int(depth);
              ss->excludedMove = move;
              ss->skipNullMove = true;
              value = search<NonPV>(pos, ss, rBeta - 1, rBeta, depth / 2);
              assert(ss->currentMove != move); //[ line 889 in current search.cpp from Stockfish]
              ss->skipNullMove = false;
              ss->excludedMove = MOVE_NONE;
              if (value < rBeta)
                  ext = ONE_PLY;
          }
      }

      // Update current move (this must be done after singular extension search)

and with the regular Stockfish search, but with evaluation modified, it soon triggers the assert in the starting position:

Stockfish 120317 by Tord Romstad, Marco Costalba and Joona Kiiski
go infinite
info depth 1 seldepth 1 score cp 76 nodes 27 nps 870 time 31 multipv 1 pv g1f3
info depth 2 seldepth 2 score cp 12 nodes 156 nps 5032 time 31 multipv 1 pv g1f3
g8f6
info depth 3 seldepth 3 score cp 64 nodes 291 nps 6191 time 47 multipv 1 pv g1f3
g8f6 b1c3
info depth 4 seldepth 4 score cp 12 nodes 567 nps 9145 time 62 multipv 1 pv g1f3
g8f6 b1c3 b8c6
info depth 5 seldepth 5 score cp 28 nodes 1113 nps 14269 time 78 multipv 1 pv g1
f3 b8c6 b1c3 g8f6 d2d4
info depth 6 seldepth 6 score cp 12 nodes 2214 nps 17712 time 125 multipv 1 pv g
1f3 b8c6 b1c3 g8f6 d2d4 d7d5
info depth 7 seldepth 7 score cp 52 nodes 3868 nps 20684 time 187 multipv 1 pv g
1f3 b8c6 b1c3 g8f6 d2d4 d7d5 c1f4
info depth 8 seldepth 11 score cp 32 nodes 19879 nps 22718 time 875 multipv 1 pv
g1f3 d7d5 d2d4 g8f6 b1c3 d8d6 f3e5 b8c6 c1f4 c6e5 d4e5
info depth 9 seldepth 11 score cp 32 nodes 22590 nps 22957 time 984 multipv 1 pv
g1f3 d7d5 d2d4 g8f6 b1c3 d8d6 f3e5 b8c6 c1f4 c6e5 d4e5
info depth 10 seldepth 13 score cp 28 nodes 38193 nps 22639 time 1687 multipv 1
pv g1f3 d7d5 d2d4 g8f6 d1d3 b8c6 b1c3 c8g4 d3b5 g4f3 g2f3
info depth 11 currmove b1c3 currmovenumber 2
info depth 11 currmove d2d4 currmovenumber 3
info depth 11 currmove d2d3 currmovenumber 4
info depth 11 currmove f2f3 currmovenumber 5
info depth 11 currmove g1h3 currmovenumber 6
info depth 11 currmove f2f4 currmovenumber 7
info depth 11 currmove c2c4 currmovenumber 8
info depth 11 currmove c2c3 currmovenumber 9
info depth 11 currmove e2e4 currmovenumber 10
info depth 11 currmove a2a4 currmovenumber 11
info depth 11 currmove a2a3 currmovenumber 12
info depth 11 currmove b2b4 currmovenumber 13
info depth 11 currmove b1a3 currmovenumber 14
info depth 11 currmove e2e3 currmovenumber 15
info depth 11 currmove g2g4 currmovenumber 16
info depth 11 currmove h2h4 currmovenumber 17
info depth 11 currmove b2b3 currmovenumber 18
info depth 11 currmove h2h3 currmovenumber 19
info depth 11 currmove g2g3 currmovenumber 20
info depth 11 seldepth 16 score cp 20 upperbound nodes 67441 nps 22250 time 3031
multipv 1 pv g1f3 d7d5 d2d4 g8f6 d1d3 b8c6 b1c3 a7a6 c1f4 c6b4
info depth 11 currmove g1f3 currmovenumber 1
info depth 11 currmove b1c3 currmovenumber 2
info depth 11 currmove d2d4 currmovenumber 3
info depth 11 currmove h2h3 currmovenumber 4
info depth 11 currmove g2g4 currmovenumber 5
info depth 11 currmove e2e4 currmovenumber 6
info depth 11 currmove d2d3 currmovenumber 7
info depth 11 currmove b1a3 currmovenumber 8
info depth 11 currmove b2b4 currmovenumber 9
info depth 11 currmove c2c4 currmovenumber 10
info depth 11 currmove a2a4 currmovenumber 11
info depth 11 currmove a2a3 currmovenumber 12
info depth 11 currmove h2h4 currmovenumber 13
info depth 11 currmove b2b3 currmovenumber 14
info depth 11 currmove f2f3 currmovenumber 15
info depth 11 currmove c2c3 currmovenumber 16
info depth 11 currmove g1h3 currmovenumber 17
info depth 11 currmove e2e3 currmovenumber 18
info depth 11 currmove f2f4 currmovenumber 19
info depth 11 currmove g2g3 currmovenumber 20
Assertion failed: ss->currentMove != move, file e:\computerchess back-up\mcostal
ba-stockfish-51e8efd\mcostalba-stockfish-51e8efd\src\search.cpp, line 889

In my own code I have made a small modification that did not help against the memory access violation exception but did stop the assert being triggered by I think the result of a hashhit. The exclusion search uses a different position key for the exclusion search so I don't really understand why it can still return the ttMove to ss->currentMove in that case? Could it be a hash result from a previous exclusion search, in the same position, but with a different excluded move maybe?

Code: Select all

    // At PV nodes we check for exact scores, while at non-PV nodes we check for
    // a fail high/low. Biggest advantage of probing at PV nodes is to have a
    // smooth experience in analysis mode. We don't probe at Root nodes otherwise
    // we should also update RootMoveList to avoid bogus output.
    if (!RootNode
		&& tte
		&& (PvNode ? tte->depth() >= depth && tte->type() == BOUND_EXACT
                                    : can_return_tt(tte, depth, beta, ss->ply))
		&& ttMove != excludedMove) //[ to avoid triggering assert(ss->currentMove != move) at line 889]

    {

(Now there is I think a possibility that excludedMove = ttMove = MOVE_NONE and now the ttresult is no longer returned even though theoretically valid. If there is no ttMove it usually is an ALL node and if now the result is a beta cutoff would you not rather search deeper anyway? But that would be a small functional change)

Eelco

[Eelco de Groot]

Alternative code:

Code: Select all

    // At PV nodes we check for exact scores, while at non-PV nodes we check for
    // a fail high/low. Biggest advantage of probing at PV nodes is to have a
    // smooth experience in analysis mode. We don't probe at Root nodes otherwise
    // we should also update RootMoveList to avoid bogus output.
    if (!RootNode
		&& tte
		&& (PvNode ? tte->depth() >= depth && tte->type() == BOUND_EXACT
                                    : can_return_tt(tte, depth, beta, ss->ply))
		&& !(excludedMove != MOVE_NONE && ttMove == excludedMove) //[ to avoid triggering assert(ss->currentMove != move) at line 889]

    {

(Now there is I think a possibility that excludedMove = ttMove = MOVE_NONE and now the ttresult is no longer returned even though theoretically valid. But that would be a small functional change)

Eelco

[mcostalba]

I am not sure it is going to matter much but it turns out the exception search can, also in Stockfish, return a ss->currentMove that is identical to the ttMove (or to move).

So what ?

I don't see any problem in setting ss->currentMove at that point. You have added additional, not needed, code just to 'fix' a non-issue IMO.

[Eelco de Groot]

I am not sure it is going to matter much but it turns out the exception search can, also in Stockfish, return a ss->currentMove that is identical to the ttMove (or to move).

So what ?

I don't see any problem in setting ss->currentMove at that point. You have added additional, not needed, code just to 'fix' a non-issue IMO.

Hello Marco,

Maybe I just don't understand the code or for that matter your codechange retiring ss->bestMove, but what I thought happened there is a beta cutoff of the exclusion search, ss->currentMove can only be interpreted as ss->bestMove if there was an actual beta cutoff but I assume that was the case. Now because of the cutoff there will be no singular extension awarded, because of I think a hash hit (assuming it is always a hashhit that causes this). The ss->bestMove/ss->currentMove and the triggered assert indicates the move causing the beta cut off was identical to the move that should have been excluded from the search. The excluded move only came back in again because there was no check of the hash content comparing the ttMove found within the exclusion search with the move that should be excluded. It is not a big deal but it seems to me it defeats the purpose of doing an exclusion search when this happens. Or am I totally missing what is happening?

In the old code I called ss->bestMove returned by the exclusion search nexbestMove and used it later on. Not with much succes sofar though. But I never actually tested the assert I had made before. I did not think it was likely to happen, because the exclusion Pos key would always have returned a result from the exclusion search in the position, not the regular search. But it does not seem to be entirely watertight. Only once in an eleven ply search but it still happens...

Regards, Eelco

[Justin Sherron]

Turns out I was wrong to assume my PGO builds were suffering from the same problem as your compiles (which should have been obvious to me since mine were crashing right out of the gates...). I still don't know exactly what caused the segmentation faults, but re-compiling after upgrading from Ubuntu 11.04 to 11.10 now produces working executables. All is well again.

[Marek Soszynski]

The original problem is now solved. Stockfish 7c8a8e0 works okay in Scid. Thanks Marco!