Author: Robert Hyatt
Date: 19:35:47 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 It is indicative of an uninitialized variable. A procedure call such as the ones above simply stomp on the stack before your code gets to use the value that was not initialized. you might try gcc -Wall -O2 to let it build a dependency graph and look for such problems. If it sees a path from the top of the procedure to the bottom, where any variable is referenced before it is initialized (local variables only) it will give you a warning...
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.