On-line engine blitz tourney October

[Joost Buijs]

The monthly on-line engine blitz tourney for October will take place on:

Saturday October 29, 2:00 PM EST (Boston time), 20:00 CET (Amsterdam time)

To connect:

winboard -zp -ics -icshost nightmare-chess.nl -icshelper timeseal -fcp ENGINE.exe -fd ENGINEFOLDER -autoKibitz -keepAlive 30

(for UCI engines, add -fUCI)

People without account can submit a request for an account to admin@nightmare-chess.nl

Our tournament manager will be: Eendje (Lisebeth at ICC)

The format will be: 9 rounds Swiss 5/1

Lisebeth likes to start the tournament on top of the hour, please try to be on-line 15 minutes prior to tournament start, late joins are not supported.

[flok]

The monthly on-line engine blitz tourney for October will take place on:

Saturday October 29, 2:00 PM EST (Boston time), 20:00 CET (Amsterdam time)

To connect:

winboard -zp -ics -icshost nightmare-chess.nl -icshelper timeseal -fcp ENGINE.exe -fd ENGINEFOLDER -autoKibitz -keepAlive 30

(for UCI engines, add -fUCI)

People without account can submit a request for an account to admin@nightmare-chess.nl

Our tournament manager will be: Eendje (Lisebeth at ICC)

The format will be: 9 rounds Swiss 5/1

Lisebeth likes to start the tournament on top of the hour, please try to be on-line 15 minutes prior to tournament start, late joins are not supported.

If all goes well, then Dog will participate running on an ESP32 microcontroller.

Please skip Dolly - too weak.

[Joost Buijs]

If all goes well, then Dog will participate running on an ESP32 microcontroller.

Please skip Dolly - too weak.

Ok, I'll tell Lisebeth that she should skip Dolly.

[Modern Times]

If all goes well, then Dog will participate running on an ESP32 microcontroller.

Dog forfeited on time in the one game I played against it.

[flok]

If all goes well, then Dog will participate running on an ESP32 microcontroller.

Dog forfeited on time in the one game I played against it.

Odd. Do you have some kind of log maybe even with timing?

[Modern Times]

No, but it isn't playing at all now.

[Modern Times]

Dog probably crashed and is now unresponsive.

[flok]

Dog probably crashed and is now unresponsive.

Something crashed indeed. But what? The microcontroller was still up, socat (the connector between the serial port and icsdrone) was still running as well as icsdrone.
Weird.
I've enabled polyglot logging, let's see.

[Modern Times]

It has just happened again, so check those logs.

It seems to handle 1+1 and 3+1 OK, it played several of those, but as soon as you ask it to play 5+1 it crashes later in the game.

[Ras]

It seems to handle 1+1 and 3+1 OK, it played several of those, but as soon as you ask it to play 5+1 it crashes later in the game.

Might be a stack problem that manifests with higher thinking times due to more depth being reached. Going via some high stack water mark runtime checks isn't what I'm doing in my microcontroller engine. Instead, I use GCC's -fstack-usage feature for individual functions, then manually put together the call stack and calculate what maximum depth I can afford with the amount of stack that I configured. That's 23 for the main search and 10 for QS on top of that.

It's also a pretty dangerous design to have the stack at the top, the heap below that, and to let them grow towards each other. I don't use any heap because it's not recommended for embedded if your controller has no MMU - memory fragmentation can become a problem if you allocate / free beyond pure initialisation. I have the stack at the bottom of its memory region because what's even more nasty than a proper crash is if it continues with data garbled up.