On-line engine blitz tourney July

[Sven]

I looked in the command log, and there is nothing suspicious there. The last logged command is a simple move, 'e3h3'.

I think we had this kind of thought already on an earlier crash of ICS. An input line that is too long will probably crash the server before it can make it into some logfile.

[Joost Buijs]

I looked in the command log, and there is nothing suspicious there. The last logged command is a simple move, 'e3h3'.

I think we had this kind of thought already on an earlier crash of ICS. An input line that is too long will probably crash the server before it can make it into some logfile.

That problem was in the timeseal decoder, it could not withstand lines longer than 1kB. HG fixed this a long time ago by replacing the external decoder by an internal one.

Anyway, it is not good practice to send very long lines to the ICS, if it doesn't crash it, it will at least hog it.

[Ras]

Maybe it would be a good idea to truncate overly long input lines at the earliest point possible to fix this once and for all. Besides, a server program crashing upon input data is a potential security vulnerability. The pasted line example is slightly more than 1 kB, so this looks like a promising trace to follow up.

[Sven]

I looked in the command log, and there is nothing suspicious there. The last logged command is a simple move, 'e3h3'.

I think we had this kind of thought already on an earlier crash of ICS. An input line that is too long will probably crash the server before it can make it into some logfile.

That problem was in the timeseal decoder, it could not withstand lines longer than 1kB. HG fixed this a long time ago by replacing the external decoder by an internal one.

Yes, that was in last summer, HGM fixed it on 6-aug-2018.

[Joost Buijs]

Any news?

[Henk]

We are free

https://www.youtube.com/watch?v=uRD_gIoVOmY

[Joost Buijs]

I like this one better:

https://www.youtube.com/watch?v=NrRzT-WmlbA

And this is from (what I think) their best album:

https://www.youtube.com/watch?v=TmfQQC1bsf4

[Henk]

I almost forgot Skipper doesn't update chessboard datastructure anymore only using magic bitboards.
But can't get rid off chessboard datastructure.

Singer of the who played in movie "the legacy". Bit boring movie by the way. So no need to watch it.
https://www.youtube.com/watch?v=q90FsyEGy24

[hgm]

Unfortunately I have been too busy this month (partly because of my trip to Macao) to look into the ICS problem. Today I had a first glance at the code. This is complex, but seems well aware of the size of the input buffer (through a #define MAX_STRING_LENGTH 1024). So I doubt the problem could have been related to that. After the second crash last months I saw a buffer-overrun error message plus a stack trace, but the trace went very deep into library function calls that were only identified by memory address, so I have no clue at all what was being attempted.

I am not sure what to do now. If we would try another tourney this Saturday, chances are that exactly the same will happen as last month. OTOH, it has been working flawlessly for nearly a year, and I don't understand why it suddenly started crashing. What can have changed?

[Joost Buijs]

Probably nothing has changed. My guess is that there still is a weak spot in the code that is sensitive to very long strings. Folkerts new program was sending PV strings way over 1KB in size, he also crashed icsDrone with it, it is very likely that this caused the problem. I guess he must have fixed this by now. Maybe the easiest is to give it another try.

I've been looking several times at the 'Lasker/Capablanca' source, it is complex ancient code, programmed in such a way that many things can go wrong, so it won't be easy to identify the problem. Some time ago I set up an ICS with the latest 'Capablanca' source, although I never use it I can try to make it crash, and if it does try to find the error location.