Author: Christophe Theron
Date: 17:21:13 04/03/00
Go up one level in this thread
On April 03, 2000 at 17:58:23, Frank Phillips wrote:
>On April 02, 2000 at 10:56:38, Robert Hyatt wrote:
>
>>On April 02, 2000 at 05:56:05, Frank Phillips wrote:
>>
>>>On April 01, 2000 at 09:31:43, Robert Hyatt wrote:
>>>
>>>>On April 01, 2000 at 09:19:52, Frank Phillips wrote:
>>>>
>>>>>I would be grateful if any Linux users could shed any light on the following:
>>>>>
>>>>>Having just upgraded from SuSe 6.2 to Mandrake 7.0 my chess program compiles but
>>>>>does not correctly update the 64bit hash codes (using xor) during the search.
>>>>>This is confirmed by a debug function which compares the incrementally updated
>>>>>value with that calculated from scratch.
>>>>>
>>>>>Mandrake gcc, version 2.95.2 19991024 seems to cause the problem.
>>>>>
>>>>>After forcing version 2.91.66 19990314 to install in Mandrake from an old
>>>>>RedHat 6.0 RPM, everything is back to normal.
>>>>>
>>>>>Frank
>>>>
>>>>
>>>>I am using 2.95.2 on redhat 6.1 and 6.2 machines... and it is working fine
>>>>for me.
>>>>
>>>>How did you conclude it is screwing up???
>>>
>>>Bob
>>>
>>>Three things:
>>>
>>>The above debug function indicates that the incrementally updated hash code for
>>>the board is different from the value calculated from scratch by scanning the
>>>board and forming the hash code as at initialisation.
>>>
>>>After (for example) 1.e4 c5 on the game board, my program is out of book.
>>>
>>>On Fine#70 I get only 14 ply in a few seconds compared to 25 or 30 normally and
>>>(because) there are almost no hash hits.
>>>
>>>None of this happens in Windows 98 or 2000 using MS VC6++. Nor with SuSe nor
>>>Mandrake and the older gcc compiler. Crafty seems to compile properly under
>>>Mandrake with gcc 2.95.2 and use the hash table, but there are warnings about
>>>two Eugene?s of the egtb functions not being defined but not used,
>>>intTbtProbeTable(?) was one.
>>>
>>>Frank
>>
>>
>>The warnings from Eugene's code are normal. They happen on all compilers
>>that I know of... And I have run the same sort of test as I have a function
>>ValidatePosition() that validates the hash key (among other things) just as
>>you suggest. I always try it on each new version of the compiler, and after
>>major changes to the program, to be sure nothing gets broken... and it doesn't
>>fail at all on 2.95...
>>
>>it sounds more likely like you might have an undefined/uninitialized variable
>>that 2.95 is putting in a different place on the stack, screwing it up...
>
>
>
>If I put
>
>getchar();
>
>or
>
>if (cin->avail->rdbuf())
> char a=getchar();
>
>
>in the MakeMove() function, then everything works fine!?
>
>Is this indicative of some class of fault, to help me trace the problem?
>
>
>Frank
Bob is probably right. I would bet that you have a LOCAL uninitialized variable.
When you do not add your debug code (the one that calls getchar), the variable
has a given value (random, but always the same because it depends of what has
been pushed on the stack before).
When you add the debug code, it puts other values in the stack (because you call
a function, so the content of the stack is changed), and that's why the
behaviour of your program changes in this case.
I have already experienced this several times. Just adding printf to my faulty
routine made it work (and consequently made debugging by printf impossible!). A
classical case I would say.
I would suggest that you turn all warnings on (option: -Wall). The GCC compiler
will maybe tell you which local variable is not initialized.
Christophe
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.