Crashing/losing connection/etc

[andygrant]

Crashing/losing connection/etc

[AndyGrant]

I'm going to take a guess and say the issue is not on Ethereal's end, because there are no problems at TCEC/CCC or with the 76,841,321 games played on OpenBench as of typing this. I'm not sure what to recommend to you. Based on your other engines not having issues, I would place the blame on the compile.

What OS are you running under? What compiler and what version did you use to build? What, if any, arguments did you pass to the makefile?

To remove the possibility of the other engine "interfering", you could run games of Ethereal vs Ethereal and see if a crash / timeloss is still produced.

If I had to take a guess, and its a wild one so its probably way off base -- I told you that Ethereal worked on Linux, but you could not build it, so you ran it inside WINE, which I imagine does not work, as I've made no effort to make that work since Ethereal is cross-platform.

I'm happy to try to help you work through this. I appreciate anyone who uses Ethereal.

[iandoug]

Hi Andy

Thanks for reply. Not running via Wine, using Linux version.

Linux trooper 4.19.44-gentoo #1 SMP Tue Jun 18 09:50:18 SAST 2019 x86_64 AMD FX(tm)-8150 Eight-Core Processor AuthenticAMD GNU/Linux

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/python --enable-languages=c,c++,objc,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.3.0-r1 p1.1' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --enable-vtable-verify --enable-lto --without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.3.0 (Gentoo 8.3.0-r1 p1.1)

Hope that helps. Running another large test (306 games) and it did okay with the first game but not the second. Again it was Komodo. Has not played Stockfish yet.
Will run H2H against itself when current test is done, which may take a while :-)

[White "Ethereal"]
[Black "komodo-10-linux"]
[Result "1/2-1/2"]
[FEN "1rbqkbr1/1nppppn1/2pppp2/8/8/2PPPP2/1NPPPPN1/1RBQKBR1 w - - 0 1"]
[GameDuration "00:13:26"]
[GameEndTime "2019-11-05T19:01:27.332 SAST"]
[GameStartTime "2019-11-05T18:48:01.072 SAST"]
[PlyCount "105"]
[SetUp "1"]
[Termination "adjudication"]
[TimeControl "180+5"]

[White "komodo-10-linux"]
[Black "Ethereal"]
[Result "1-0"]
[FEN "1rbqkbr1/1nppppn1/2pppp2/8/8/2PPPP2/1NPPPPN1/1RBQKBR1 w - - 0 1"]
[GameDuration "00:17:52"]
[GameEndTime "2019-11-05T19:19:30.064 SAST"]
[GameStartTime "2019-11-05T19:01:37.071 SAST"]
[PlyCount "147"]
[SetUp "1"]
[Termination "stalled connection"]
[TimeControl "180+5"]

Will revert later. Is there maybe a debug mode?

Thanks, Ian

[AndyGrant]

There is not really a "debug" mode for Ethereal, but there is a compile flag which enables a handful of asserts. You could try doing make debug, and then running from the command line
./Ethereal bench <depth> <threads> <hash>

Replace all the <XYZ> with your own options. Preferably the threads and hash values you are using in your games, and then start the depth at something small like 15. I don't think this will give us any information, but if it were to crash on the bench, that would mean something.

Last thing I can suggest is to pass the -debug flag to cutechess-cli (Not sure how to force debug logging in the GUI) and then upload that file somewhere after a crash. I'm really at a loss for advice, since I don't have anyone else reporting any issues.

Are you using Tablebases?

[iandoug]

Hi
I did install games-board/tablebase-syzygy but I see that CuteChess option to use it was not ticked.

The test I was running eventually died due to engine List512 ... this engine was non-responsive at the start of every game, but looks like CuteChess finally got fed up with it and stopped the tournament.

The engines that gave problems are listed below. There were 18 engines in the tournament, these are the ones that ended abnormally.

I see it's a few have trouble with Ethereal, while Herman has other issues. I'm assuming that "time forfeit" means engine went away. I noticed some messages like this:
Engine Ethereal(44): no response to ping (also for Herman).

Don't know if you know, but in S16 on TCEC, Stockfish died twice, both times against Allie, and the problem was traced to a 3rd-party DLL file. So possibly a 3rd-party .so file / whatever on my system is causing the issues.

Let me run a mini-test with Stockfish, Komodo, rofChade, Fire, Arminius and Ethereal using normal start position, and see how it goes. I have been testing a non-standard start position so I need to eliminate that as a cause.

komodo-10-linux Ethereal 1-0 stalled connection
Ethereal Hermann_2.7.1_64 0-1 stalled connection
Hermann_2.7.1_64 Ethereal 1-0 stalled connection
Ethereal Fire_7.1_x64 0-1 time forfeit
Fire_7.1_x64 Ethereal 1-0 time forfeit
Ethereal Arminius_2017-01-01-modern_64 0-1 time forfeit
Adachess laser 0-1 illegal move
stockfish Ethereal 1-0 time forfeit
Ethereal stockfish 0-1 time forfeit
komodo-10-linux Hermann_2.7.1_64 1-0 stalled connection
rofChade Ethereal 1-0 time forfeit
Ethereal rofChade 0-1 time forfeit
Adachess Hermann_2.7.1_64 1-0 stalled connection
Hermann_2.7.1_64 Adachess 0-1 stalled connection
Hermann_2.7.1_64 Fire_7.1_x64 0-1 stalled connection
Fire_7.1_x64 Hermann_2.7.1_64 1-0 stalled connection
gaviota-1.0-linux64 Ethereal 1-0 time forfeit
Ethereal gaviota-1.0-linux64 0-1 time forfeit
Adachess Ethereal 1-0 stalled connection

Cheers, Ian

[AndyGrant]

I have on thought, and its a silly one, but its possible that cutechess is this picky. I've made a new branch. As a part of the UCI specification, the GUI may send isready to engines. The expectation is that the engine responds with readyok. Technically, I think this command is a misnomer. Since if Ethereal is currently searching, Ethereal is NOT ready. However, In the branch I linked I tweaked Ethereal to always respond to pings. This could fix the issue.

Its also possible that there seems to be an issue with flushing the standard output. This work explain false "stalled connections", as well as "time forfeits". That would be harder to address as I do not have a machine running on your conditions, but I would expect this is not the case as I personally use Ubuntu 18 and do not have any issues.

[iandoug]

Hi Andy

Okay it looks like I've isolated the issue. The problems occur when I check the option in CuteChess GUI to allow "Thinking on opponent's time". So I guess that there's maybe a third-party library that some engines use and that gets tied in knots, or possibly a problem with CuteChess itself. Though I suspect it may be a library issue.

Anyway, FWIW, results of the tests, first was seven-engine round robin playing normal chess, the engines decided the opening books themselves I think. Second was a five-engine round robin using my non-standard setup, and thus no opening books.

Rank Name Elo +/- Games Score Draws
1 stockfish 191 144 12 75.0% 50.0%
2 komodo-10-linux 154 171 12 70.8% 41.7%
3 rofChade 89 165 12 62.5% 41.7%
4 Ethereal 89 132 12 62.5% 58.3%
5 Fire_7.1_x64 58 176 12 58.3% 33.3%
6 gaviota-1.0-linux64 -338 nan 12 12.5% 8.3%
7 Arminius_2017-01-01-rn_64 -417 nan 12 8.3% 0.0%

and
Rank Name Elo +/- Games Score Draws
1 stockfish 255 286 8 81.3% 37.5%
2 Ethereal 137 241 8 68.8% 37.5%
3 Fire_7.1_x64 -44 216 8 43.8% 37.5%
4 komodo-10-linux -44 216 8 43.8% 37.5%
5 rofChade -338 nan 8 12.5% 0.0%

I'll post a query on the CuteChess repo and see what they think.

Thanks, Ian

[AndyGrant]

Well thats pondering, which might make it even more likely that the branch I suggested resolves the issue. If you don't mind, I would be interested to see if you can build the branch and see if it resolves the issue.

[iandoug]

Sorry, I somehow overlooked your reply from two hours ago. Hopefully my reply above will shed light in the correct direction if it is an issue.
Okay will try the new branch later.
Possibly Herman engine has the same issue.
Will revert.

[AndyGrant]

Whether that resolved your issue or not, I have merged that branch with master at the same time as adding support for multiPV 27eb02c . I'm fairly sure that was the issue. Thank you for bringing this to my attention.

[iandoug]

Thanks, have downloaded your latest version. Here's an interesting mate for you. Who needs a free queen when you can have mate instead?.....

BTW it might be useful to add a "-v" switch to print out the version number.

[White "Ethereal 20191110"]
[Black "Alaric707"]
[Result "1-0"]
[FEN "1rbqkbr1/1nppppn1/2pppp2/8/8/2PPPP2/1NPPPPN1/1RBQKBR1 w - - 0 1"]
[GameDuration "00:12:15"]
[GameEndTime "2019-11-12T22:17:05.121 SAST"]
[GameStartTime "2019-11-12T22:04:50.062 SAST"]
[PlyCount "85"]
[SetUp "1"]
[TimeControl "180+5"]

1. e4 {+0.15/22 11s} d5 {-0.15/17 12s} 2. Ne3 {+0.25/23 18s} Rh8 {-0.12/17 15s} 3. d4 {+0.39/23 11s} Nd6 {-0.04/16 10s} 4. d3 {+0.34/24 7.1s} Nh5 {-0.10/16 24s} 5. Bd2 {+0.64/21 8.9s} Ra8 {0.00/16 10s} 6. c4 {+1.09/21 8.4s} dxe4 {-0.19/16 14s} 7. fxe4 {+1.02/23 8.8s} Bh6 {-0.28/16 14s} 8. Ng2 {+1.70/23 16s} Bxd2+ {-0.10/16 14s} 9. Kxd2 {+1.40/23 16s} Ng7 {-0.18/16 10s} 10. e5 {+1.32/23 15s} Nb7 {-0.28/15 8.3s} 11. e4 {+1.44/22 11s} Kf8 {0.00/14 8.2s} 12. Qg4 {+1.65/23 10s} d6 {+0.02/14 12s} 13. exf6 {+1.80/23 9.5s} exf6 {-0.14/16 8.0s} 14. Ne3 {+1.85/24 7.3s} Ne8 {-0.22/16 9.1s} 15. Qf3 {+1.73/23 7.1s} e5 {-0.15/16 8.8s} 16. d5 {+1.85/24 6.6s} Bd7 {-0.35/16 19s} 17. Rh1 {+3.63/23 13s} Rg8 {-0.56/15 7.0s} 18. Qh5 {+3.66/22 7.5s} Nc5 {-0.82/15 15s} 19. Bh3 {+3.86/22 8.1s} Bxh3 {-0.94/14 9.1s} 20. Qxh3 {+6.10/20 10s} cxd5 {-1.20/13 7.8s} 21. Rhg1 {+7.97/22 12s} Ng7 {-2.18/14 11s} 22. cxd5 {+8.16/22 9.0s} c6 {-2.33/13 6.2s} 23. Qh6 {+10.82/21 16s} Qa5+ {-2.59/12 6.2s} 24. Ke2 {+12.34/21 14s} cxd5 {-3.52/13 12s} 25. Nxd5 {+13.59/23 13s} Ne6 {-4.31/13 8.5s} 26. Nc4 {+13.87/21 7.4s} Qd8 {-4.64/12 5.8s} 27. Nxf6 {+16.43/21 14s} Ra6 {-6.96/13 17s} 28. Kd2 {+18.93/20 10s} Rc6 {-8.18/13 5.3s} 29. Ne3 {+23.00/21 14s} Rc8 {-8.48/12 5.3s} 30. Nxg8 {+24.69/18 5.4s} Qa5+ {-10.70/11 10s} 31. Kd1 {+28.26/18 5.0s} Qa2 {-12.12/12 5.5s} 32. Rc1 {+29.75/18 5.0s} Rxc2 {-14.94/12 5.1s} 33. Rxc2 {+41.06/19 5.0s} Qb1+ {-19.92/11 5.0s} 34. Rc1 {+M27/26 5.0s} Qxd3+ {-19.92/11 5.0s} 35. Ke1 {+M17/34 3.0s} Qa6 {-M20/11 5.0s} 36. Rxg7 {+M15/37 3.5s} Qa5+ {-M16/9 5.0s} 37. Kf1 {+M13/40 3.8s} Qb5+ {-M12/11 0.91s} 38. Kg1 {+M11/45 3.5s} Qd7 {-M10/8 0.14s} 39. Nf6 {+M9/48 2.8s} Nxg7 {-M8/6 0.002s} 40. Qh8+ {+M7/70 2.8s} Ke7 {-M6/4 0.001s} 41. Ned5+ {+M5/117 15s} Ke6 {-M4/4 0.001s} 42. Qh3+ {+M3/127 0.040s} Nf5 {-M2/3 0s} 43. exf5# {+M1/127 0.002s, White mates} 1-0