More Crafty 23.6 problems

[Lars]

If compiling for Windows / 1 cpu using Visual Studio it does not work at all.

The following code in the new SearchFH:

if (tree->nodes_searched > noise_level || (tree->parent &&
tree->parent->nodes_searched > noise_level)) {

Will give Access violation as tree->parent is not initialized to NULL.

Also there are several funny problems to get it to compile at all.

Lars

[Sven]

Hi Lars,

I had no trouble to compile it with VS2010 Express using the flags that are given in "Makefile.xp". Most of the compiler warnings do not look suspicious to me (even though I'd prefer to fix them). But for me it crashes as well, although it seems it crashes at a different place than the one you gave below (I can't even tell exactly where since the debugger itself is not sure and the call stack looks fishy ...). The whole thing smells like some uninitialized memory.

Of course it may be simply a compile issue.

Sven

[velmarin]

Hello my friend,

I compiled with Visual Studio 2012, Visual C + + , warnings by decrepeted, ect, but perfect.

Also with Intel compiler on Visual Studio, perfect, Intel is more permissive.
Explain more your problem, version, ect.

[Sven]

Hi Lars,

I had no trouble to compile it with VS2010 Express using the flags that are given in "Makefile.xp". Most of the compiler warnings do not look suspicious to me (even though I'd prefer to fix them). But for me it crashes as well, although it seems it crashes at a different place than the one you gave below (I can't even tell exactly where since the debugger itself is not sure and the call stack looks fishy ...). The whole thing smells like some uninitialized memory.

Of course it may be simply a compile issue.

Sven

After taking a second look I can now confirm the same crash as in the initial post. The call stack is:
main - Iterate - Search - SearchFH
and tree->parent is 0xcdcdcdcd in line 952 of search.c, i.e. uninitialized. Not sure how that can happen, though, but it happens.

I started the Release version from Visual Studio and entered these standard commands to reproduce the crash:
xboard
protover 2
new
level 40 5 0
go

The same happens in the Debug version.

Sven

[Sven]

Hello my friend,

I compiled with Visual Studio 2012, Visual C + + , warnings by decrepeted, ect, but perfect.

Also with Intel compiler on Visual Studio, perfect, Intel is more permissive.
Explain more your problem, version, ect.

I think the main problem is the crash.

[bob]

If compiling for Windows / 1 cpu using Visual Studio it does not work at all.

The following code in the new SearchFH:

if (tree->nodes_searched > noise_level || (tree->parent &&
tree->parent->nodes_searched > noise_level)) {

Will give Access violation as tree->parent is not initialized to NULL.

Also there are several funny problems to get it to compile at all.

Lars

I will give it a quick look. I don't normally compile without SMP support since I don't have any machine anywhere that has just one core. Best advice to fix it quick is use -DCPUS=2 which will make it work just fine...

[bob]

Hi Lars,

I had no trouble to compile it with VS2010 Express using the flags that are given in "Makefile.xp". Most of the compiler warnings do not look suspicious to me (even though I'd prefer to fix them). But for me it crashes as well, although it seems it crashes at a different place than the one you gave below (I can't even tell exactly where since the debugger itself is not sure and the call stack looks fishy ...). The whole thing smells like some uninitialized memory.

Of course it may be simply a compile issue.

Sven

After taking a second look I can now confirm the same crash as in the initial post. The call stack is:
main - Iterate - Search - SearchFH
and tree->parent is 0xcdcdcdcd in line 952 of search.c, i.e. uninitialized. Not sure how that can happen, though, but it happens.

I started the Release version from Visual Studio and entered these standard commands to reproduce the crash:
xboard
protover 2
new
level 40 5 0
go

The same happens in the Debug version.

Sven

It might happen if the SMP code is compiled out. I'll look, but without SMP support, tree->parent won't be initialized since there is no "parent". As I mentioned previously, I never compile without -DCPUS=2 at least, since there are no single-core boxes anywhere I can reach. In that light, compiling without SMP support doesn't make a lot of sense, but it should work.

I'll test to see what is happening...

[bob]

I just uploaded a new 23.6 source to the usual place. the problem was that block[0]->parent was not zero in windows, apparently, where in Unix it defaults to zero. This should fix the problem...