Floyd 0.5 released

[hgm]

Thanks for the data. I don't understand yet what is happening. When I look at one of the 40/2 games (the first one), time usage looks normal up to that last move.

Usually that means the engine crashed during the search of the next move, and just hangs until it is flagged, dead as a Dodo.

[mvk]

Thanks for the data. I don't understand yet what is happening. When I look at one of the 40/2 games (the first one), time usage looks normal up to that last move.

Usually that means the engine crashed during the search of the next move, and just hangs until it is flagged, dead as a Dodo.

From what I can see in some of Gabor's UCI logging, at some point the usual preparations for starting the search thread are done (calculating the time target), but then the search thread itself doesn't kick off. Hash usage and UCI communications look normal prior to such point. So either the thread doesn't start, or it crashes and it goes unnoticed. But if that can happen, then this must be unrelated to the Shredder GUI and could happen under any GUI running the w64 binary, I suppose. Still don't know what it is, but getting closer.

[mvk]

However, it makes the last couple of moves before time control in 0 seconds which often leads to spoiling its position.

That part is normal and will already improve in the next version

[Joost Buijs]

The hash problem is caused by an Arena bug.
It seems Arena wants to have the hash parameters in the following order:
min, max, default.

The 64 bit bug is caused by a typo in the in the function createThread()

struct threadClosure *closure = malloc(sizeof(closure));

should of course be

struct threadClosure *closure = malloc(sizeof(struct threadClosure));

I guess the bug is also present in the 32 bit version???
Somehow the 32 bit version seems to have less problems with it.

When you release a new version of the source I can make another 64 bit Windows build for it (if needed).

[mar]

The 64 bit bug is caused by a typo in the in the function createThread()

struct threadClosure *closure = malloc(sizeof(closure));

should of course be

struct threadClosure *closure = malloc(sizeof(struct threadClosure));

Nice find, I guess Marcel wanted to type *closure
This is where static analyzers come in handy, cppcheck finds this easily (cplus.c, lines 261 and 302).
It also claims out of bounds access (idx 64) in moves.c, line 325, but this may be a false positive.

[Joost Buijs]

The hash problem is caused by an Arena bug.

Then why does it stop playing around move 30 under Shredder?

This is caused by the other problem, some memory locations are unintentionally overwritten which causes the problems you saw.
I have no clue why the 32 bit version has no problem with it.
A totally different compiler, different alignment, who knows.

[mar]

I have no clue why the 32 bit version has no problem with it.
A totally different compiler, different alignment, who knows.

I think the allocator automatically aligns to 8 bytes (and allocates in 8-byte quanta), threadClosure fits in 8 bytes in 32 bit mode but not in 64 bit mode.

[Joost Buijs]

The 64 bit bug is caused by a typo in the in the function createThread()

struct threadClosure *closure = malloc(sizeof(closure));

should of course be

struct threadClosure *closure = malloc(sizeof(struct threadClosure));

Nice find, I guess Marcel wanted to type *closure
This is where static analyzers come in handy, cppcheck finds this easily (cplus.c, lines 261 and 302).
It also claims out of bounds access (idx 64) in moves.c, line 325, but this may be a false positive.

Visual Studio has static analysis as well, but I simply forgot to use it.
The heap was getting corrupted, but I didn't know why, it took me about 2 hours to find this manually.

[Joost Buijs]

I have no clue why the 32 bit version has no problem with it.
A totally different compiler, different alignment, who knows.

I think the allocator automatically aligns to 8 bytes (and allocates in 8-byte quanta), threadClosure fits in 8 bytes in 32 bit mode but not in 64 bit mode.

You are right, this is the explanation.
In 32 bit mode 4 bytes are allocated, because the default alignment is 8 bytes two 4 byte pointers are causing no harm.

[mvk]

Indeed, I have looked at sizeof(closure) several times without "seeing" it, so this a great find. I'm preparing a 0.6 release will all fixes found last week, plus a little bit of elo added.

I suppose the line 325 warning is only false because pawns shouldn't be on the last rank. I will think about how to silence it in a version after 0.6.