On-line engine blitz tourney February

[Joost Buijs]

There are very weird constructions in the source, for instance things this:

if (onColor >= 0 && onPiece >= 0) // allow placement in holdings
gs->holding[onColor == BLACK][onPiece-1]++;

The index goes very likely out of bounds if onPiece == 0, to fix this I first have to find out what onPiece exactly does. And there are many things like this in the source.

I don't know if it's worthwhile to fix this mess.

oof, maybe onPiece was supposed to be > 0? this looks like some code for a variant, hard to say

in general - maybe worth giving it a shot with address/thread sanitizer enabled to see if it finds something,
unlike static analyzers they are reliable

I will try to fix everything that is obvious, and it's a good idea to run the address sanitizer on it. Debugging it is cumbersome because I have to run 'real' tournaments for it to succeed.

It could be that one of the participants sends malformed commands or data that breaks the parser(s) somewhere, fscanf and sscanf are used throughout, these are very unsafe functions, and I don't think 'safe' string-functions like sscanf_s are available for Linux compilers (at least not officially).

[flok]

and I don't think 'safe' string-functions like sscanf_s are available for Linux compilers (at least not officially).

of course they are
you could've googled that

[Joost Buijs]

and I don't think 'safe' string-functions like sscanf_s are available for Linux compilers (at least not officially).

of course they are
you could've googled that

I've googled a lot. It seems these functions are added to the C11 specification (Annex-K), but most compilers didn't implemented them.
Mayby there are 3th party libs, I don't know, It's usually not a good idea to use stuff that has not been tested thoroughly.

[hgm]

There are very weird constructions in the source, for instance things this:

if (onColor >= 0 && onPiece >= 0) // allow placement in holdings
gs->holding[onColor == BLACK][onPiece-1]++;

The index goes very likely out of bounds if onPiece == 0, to fix this I first have to find out what onPiece exactly does. And there are many things like this in the source.

I don't know if it's worthwhile to fix this mess.

This is in board.c, where start positions are set up according to instructions read from a file. This particular statement occurs in case the file specifies that the game in question uses 'holdings' for captured pieces that can be dropped as in Crazyhouse / Bughouse / Shogi. The onPiece-1 actually is onPiece-PAWN, where PAWN has the lowest code of any piece, and onPiece is set to the piece code when the board parser reads the corresponding piece ID ('P' for a Pawn) in the startposition file. onPiece is initialized to -1 at its declaration. The value of onPiece is set in the switch statement just before these lines, which does not contain a case that would set it to 0.

So this line cannot cause any problems. Certainly not in normal Chess, which does not start with piece 'in hand'.

[Joost Buijs]

There are very weird constructions in the source, for instance things this:

if (onColor >= 0 && onPiece >= 0) // allow placement in holdings
gs->holding[onColor == BLACK][onPiece-1]++;

The index goes very likely out of bounds if onPiece == 0, to fix this I first have to find out what onPiece exactly does. And there are many things like this in the source.

I don't know if it's worthwhile to fix this mess.

This is in board.c, where start positions are set up according to instructions read from a file. This particular statement occurs in case the file specifies that the game in question uses 'holdings' for captured pieces that can be dropped as in Crazyhouse / Bughouse / Shogi. The onPiece-1 actually is onPiece-PAWN, where PAWN has the lowest code of any piece, and onPiece is set to the piece code when the board parser reads the corresponding piece ID ('P' for a Pawn) in the startposition file. onPiece is initialized to -1 at its declaration. The value of onPiece is set in the switch statement just before these lines, which does not contain a case that would set it to 0.

So this line cannot cause any problems. Certainly not in normal Chess, which does not start with piece 'in hand'.

It could be that this is not a problem, but it is what I call 'sloppy coding'.

I'm thinking about removing all the 'variants' stuff and the support for older versions of the database. We want to play normal chess on the server, no Crazyhouse, Bughouse or whatever.

The parsers are a mess, if they somehow get a too long or malformed string as input it will cause a buffer overflow. Fixing all the things that potentially could go wrong is probably not worth the time it would take.

[hgm]

That would probably give you a much less reliable server, as in addition to implementing the variant support I fixed many bugs.

It might also be hard to find a version from before FICS supported Bughouse. And a version that old would probably be even more buggy.

[Joost Buijs]

That would probably give you a much less reliable server, as in addition to implementing the variant support I fixed many bugs.

It might also be hard to find a version from before FICS supported Bughouse. And a version that old would probably be even more buggy.

I agree this could be a problem. Writing something completely new in C++ or rust will probably take less time than trying to find all the bugs that still exist in the 'Lasker' code.

I want to fix all the obvious bugs that are still there, use CMake to build chessd, and run some test-tournaments. If the server still gives problems after this I will call it a day.

[jshriver]

I agree this could be a problem. Writing something completely new in C++ or rust will probably take less time than trying to find all the bugs that still exist in the 'Lasker' code.

I'm tempted to create a barebones version in rust. As a socket based i/o bridge it wouldn't be hard. Been reading up on tournament management and figure creating a new "mamer" would be the most time consuming.

In the land of web-everything it's really down to time and best approach. I was able to get lasker working under ubuntu 24.04 on a raspberry pi just so I can re-learn the basic commands and interactions. Lots could be gutted. If the end goal is not really a full ICS where people chat, have different rooms, etc. Just a single server people can connect to and allow it to act as a middle man for standard chess matches. That's within my capabilities, definitely in python, but leaning toward rust.

[tttony]

I just git clone https://github.com/ddugovic/capablanca -> here and right now Im trying to get rid of the compiler warnings so I can check with a static analyzer to hunt bugs

I will try to fix the bugs but the code is a mess, the code style is different in some files, I cant use clang format because in the compilation process it parses some files to generate other files so these files cant be formatted

Sadly I dont know rust, I was thinking using zig but after I saw the code, it will take some time to finish it, so Im giving a try to fix the bugs, but I would like to know what is better for the community here before embarking for the hunt

[Joost Buijs]

It generates proto.h, vers.h, parse_info.h and autoheaders.h during the build process, probably the easiest is to remove autoheaders completely.

The code uses very ancient POSIX stuff like gettimeofday, getopt and more of these, clang doesn't seem to have a problem with it, but for GCC you have to define '_POSIX_C_SOURCE 199309L' before reading in the library headers to get it working.

'gettimeofday' is deprecated, maybe the easiest is to replace it with 'clock_gettime(CLOCK_MONOTONIC, &xx)'.