In rare cases only abbreviated Stockfish output

[Mercutio1243]

I am using Stockfish to identify valuation and best continuation (PV) for a position. For this, I use the commands

position fen FEN
go movetime 150

Normally, this works very fine with output in the following format:

info string NNUE evaluation using nn-ad9b42354671.nnue enabled
info depth 1 seldepth 1 multipv 1 score cp 18 nodes 20 nps 6666 hashfull 0 tbhits 0 time 3 pv e2e4
info depth 2 seldepth 2 multipv 1 score cp 46 nodes 66 nps 22000 hashfull 0 tbhits 0 time 3 pv d2d4
info depth 3 seldepth 2 multipv 1 score cp 51 nodes 120 nps 40000 hashfull 0 tbhits 0 time 3 pv e2e4
info depth 4 seldepth 2 multipv 1 score cp 58 nodes 144 nps 48000 hashfull 0 tbhits 0 time 3 pv d2d4
info depth 5 seldepth 2 multipv 1 score cp 58 nodes 174 nps 58000 hashfull 0 tbhits 0 time 3 pv d2d4 a7a6
info depth 6 seldepth 7 multipv 1 score cp 34 nodes 1303 nps 260600 hashfull 0 tbhits 0 time 5 pv e2e4 c7c5 g1f3 b8c6 c2c3
info depth 7 seldepth 6 multipv 1 score cp 29 nodes 3126 nps 347333 hashfull 1 tbhits 0 time 9 pv d2d4 g8f6 e2e3 d7d5 c2c4 d5c4
info depth 8 seldepth 7 multipv 1 score cp 26 nodes 5791 nps 445461 hashfull 4 tbhits 0 time 13 pv g1f3 g8f6 d2d4 d7d5 e2e3
info depth 9 seldepth 9 multipv 1 score cp 31 nodes 8541 nps 474500 hashfull 5 tbhits 0 time 18 pv g1f3 c7c5 e2e4 e7e6 d2d4 c5d4 f3d4
info depth 10 seldepth 13 multipv 1 score cp 25 nodes 20978 nps 537897 hashfull 10 tbhits 0 time 39 pv e2e4 c7c5 g1f3 b8c6 f1c4 e7e6 e1g1 g8f6
info depth 11 seldepth 13 multipv 1 score cp 32 nodes 29040 nps 537777 hashfull 14 tbhits 0 time 54 pv e2e4 c7c5 c2c3 g8f6 e4e5 f6d5 d2d4
info depth 12 seldepth 14 multipv 1 score cp 38 nodes 41207 nps 564479 hashfull 18 tbhits 0 time 73 pv e2e4 e7e6 d2d4 d7d5 b1c3 d5e4 c3e4
info depth 13 seldepth 15 multipv 1 score cp 31 nodes 60308 nps 579884 hashfull 25 tbhits 0 time 104 pv e2e4 c7c5 g1f3 d7d6 d2d4 c5d4 f3d4 b8c6 c1e3 g8f6 b1c3 g7g6
info depth 14 seldepth 18 multipv 1 score cp 35 nodes 97789 nps 578633 hashfull 44 tbhits 0 time 169 pv d2d4 g8f6 c2c4 e7e6 g1f3 d7d5 g2g3 f8e7 b1c3 c7c5
info depth 15 seldepth 21 multipv 1 score cp 31 nodes 142447 nps 560814 hashfull 64 tbhits 0 time 254 pv d2d4 g8f6 c2c4 e7e6 g1f3 d7d5 c1g5 f8e7 b1c3 e8g8 e2e3 h7h6 g5h4 f6e4 h4e7 d8e7
info depth 16 seldepth 21 multipv 1 score cp 40 nodes 199887 nps 552174 hashfull 88 tbhits 0 time 362 pv d2d4 d7d5 c2c4 d5c4 g1f3 a7a6 b1c3 c7c6 a2a4
info depth 17 seldepth 19 multipv 1 score cp 32 nodes 268004 nps 552585 hashfull 120 tbhits 0 time 485 pv d2d4 g8f6 c2c4 e7e6 g2g3 d7d5 g1f3 f8e7 f1g2 e8g8 e1g1 c7c5 c4d5 e6d5 b1c3 h7h6 d4c5 e7c5
info depth 18 seldepth 19 multipv 1 score cp 32 nodes 277075 nps 553043 hashfull 122 tbhits 0 time 501 pv d2d4 g8f6 c2c4 e7e6 g2g3 d7d5 g1f3 f8e7 f1g2 e8g8 e1g1 c7c5 c4d5 e6d5 b1c3 h7h6 d4c5 e7c5
bestmove d2d4 ponder g8f6

I use the second to last line to automatically extract the information needed. However, in very rare cases (maybe 1 in 10.000?), Stockfish provides the output in an unexpected format as follows:

info string NNUE evaluation using nn-ad9b42354671.nnue enabled 
bestmove b2b3

This seems to happen quite randomly.

Can anybody please explain, what would trigger Stockfish to provide a result like the one above and how I might avoid it?

With the approach, I was relying on the UCI documentation, which states that the info part should always be included:

Directly before that the engine should send a final "info" command with the final search information, the the GUI has the complete statistics about the last search.

Ps: I am using Stockfish 15.1

[PGG106]

a fen of a position where you get a lone "bestmove" output would definitely be helpful

[Mercutio1243]

@PGG106 Yes, definitely, but I am afraid, I cannot provide this as of now: I have a large set of fens where it has happened for someone else but when running through the fens myself, the error did not occur.

I will set something up to identify a specific fen going forward. In the meantime, if anybody has any ideas, I would still be super grateful!

[PGG106]

are you using books perchance? there are sf forks that allow polyglot books for example

[Mercutio1243]

I am using Stockfish 15.1 as is, without manually adding any opening book database - if this is what you are referring to?

[Mercutio1243]

In general, I am correct in the assumption that this output should generally not occur?

[PGG106]

yes, the output is weird (but not impossible), but it's hard to tell what is happening without being able to reproduce it, why are you using an sf version that is so old?

[bftjoe]

Are you really using only 150 milliseconds?

[Mercutio1243]

I can only reiterate that the 150 ms movetime works splendidly in the 99.9999% of non-error cases, where I get a valid first impression on the position with a depths of 18-23, fully sufficient for my use case. But from the discussion, I am not sure that you are not open to my experience here.

Apart from my personal view, as mentioned above the UCI protocol explicitly requires an info line before final bestmove statement without a minimum move time, ensuring that parsing the output works in standardized way.

So, if there is a code fix that assures output conformity, this might be a plus for everyone involved, independent of the individual move time preference?

[bftjoe]

There is nothing valid about setting such a low time, regardless of whether it works most of the time or not. You are abusing the engine. It is unfortunate that you continue to disregard people that actually understand the code.

Why would someone need to be open to your stubbornness to configure the engine properly?

There could be many things going on here, such as other loads on the machine taking up most of the 150 milliseconds you assigned to analyze each position.

[Disservin]

I don’t see how setting 150ms movetime is abusing the engine. Stockfish should report a final last uci line, if it doesn’t it’s not optimal

[bftjoe]

The easiest fix would be to initialize callsCnt to 512 or any other bigger number than 0.

[bftjoe]

Also, Stockfish violates UCI spec many ways, such as not accepting upper case in bool option values, requiring searchmoves to be at end of line, etc. This is hardly the first or last violation of the spec.

Technically, every engine that has file options and runs on Linux violates the UCI spec because it requires case insensitive paths and file names, which is not really possible on Linux because they are case sensitive.

I am looking forward to you submitting many 150ms per position tests to fishtest since this is not an abuse of the engine.