Engine always panics when using sudden-death time control

[mikeleany]

Just wanted to let you know that it looks like the engine always panics when using sudden-death time control. I first tried with release version 1.2.3, then tried with v1.3.1 from the master branch. Below is the output when running the debug target with RUST_BACKTRACE=1 and entering the UCI commands by hand.

uci
id name FoxSEE 1.3.1
id author Zixiao Han
uciok
isready
readyok
ucinewgame
position startpos moves e2e4
go wtime 58000 btime 60000
thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 5', /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libcore/slice/mod.rs:2796:10
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1028
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:188
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:205
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:464
  11: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:373
  12: rust_begin_unwind
             at src/libstd/panicking.rs:302
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:139
  14: core::panicking::panic_bounds_check
             at src/libcore/panicking.rs:96
  15: <usize as core::slice::SliceIndex<[T]>>::index
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libcore/slice/mod.rs:2796
  16: core::slice::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libcore/slice/mod.rs:2647
  17: <alloc::vec::Vec<T> as core::ops::index::Index<I>>::index
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/liballoc/vec.rs:1861
  18: foxsee::uci::process_time_control
             at src/uci.rs:112
  19: foxsee::uci::process_go_cmd
             at src/uci.rs:83
  20: foxsee::uci::process_uci_cmd
             at src/uci.rs:68
  21: foxsee::main
             at src/main.rs:28
  22: std::rt::lang_start::{{closure}}
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  23: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:48
  24: std::panicking::try::do_call
             at src/libstd/panicking.rs:287
  25: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
  26: std::panicking::try
             at src/libstd/panicking.rs:265
  27: std::panic::catch_unwind
             at src/libstd/panic.rs:396
  28: std::rt::lang_start_internal
             at src/libstd/rt.rs:47
  29: std::rt::lang_start
             at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
  30: main
  31: __libc_start_main
  32: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Thanks.

[redsalmon91]

Thank you, Mike. Sudden death tc is currently not supported. I will need to add new time management mechanism for finite time controls.

[mikeleany]

Thank you. Overall it's a pretty good, stable engine. I've been running games with it through the night to see if it would be a good engine to test my own engine against. I did find just one other issue in that testing. In the following game, FoxSEE tries to castle queen-side after already having castled king-side.

[Event "Computer Chess Game"]
[Site "-"]
[Date "2020.02.10"]
[Round "24"]
[White "FoxSEE 1.3.1"]
[Black "Tinman v0.1.2"]
[Result "0-1"]

1. e4 e5 2. Nf3 Nc6 3. Bc4 Bc5 4. d3 Nf6 5. c3 d6 6. b4 Bb6 7. a4 a6 8. a5 Ba7
9. Ng5 O-O 10. O-O Bg4 11. Qb3 Bh5 12. Nd2 h6 13. Ngf3 Ng4 14. h3 Nxf2 15. Rxf2
Bxf2+ 16. Kxf2 Qd7 17. Bb2 Rad8 18. Ke1 g5 0-1
{polyglot: resign (illegal engine move by white: e1c1)}

Thanks.

[redsalmon91]

Thank you. Overall it's a pretty good, stable engine. I've been running games with it through the night to see if it would be a good engine to test my own engine against. I did find just one other issue in that testing. In the following game, FoxSEE tries to castle queen-side after already having castled king-side.

[Event "Computer Chess Game"]
[Site "-"]
[Date "2020.02.10"]
[Round "24"]
[White "FoxSEE 1.3.1"]
[Black "Tinman v0.1.2"]
[Result "0-1"]

1. e4 e5 2. Nf3 Nc6 3. Bc4 Bc5 4. d3 Nf6 5. c3 d6 6. b4 Bb6 7. a4 a6 8. a5 Ba7
9. Ng5 O-O 10. O-O Bg4 11. Qb3 Bh5 12. Nd2 h6 13. Ngf3 Ng4 14. h3 Nxf2 15. Rxf2
Bxf2+ 16. Kxf2 Qd7 17. Bb2 Rad8 18. Ke1 g5 0-1
{polyglot: resign (illegal engine move by white: e1c1)}

Thanks.

Wow, I really appreciate this finding, Mike! I have ran some "black-box" testing matches but have not looked into the PGNs to see if there is any errors. I will create a patch for this now.

[redsalmon91]

Resolved. Thanks again!