On 01/02/2011 01:07 PM, Gerd Lorscheid wrote: > Hello, > > I had a look into the history on sourceforge and did not find a related > change. So it must be an old problem. Computers are faster now and so the > search depth of this engine. This can be a reason for increased impact. Once > you have such a problem you do not know what happens. It can overwrite > something, which later on destroys something else. When debugging with > VisualStudio I set a breakpoint to a change of the language variable and it > stopped at this source location. As it was optimized code I had no access to > the hashflag variable value, so I am not sure what was going on. > > Gerd
Hi, Sure you must be right with your assessment (including your observation that this hasflag count logging is for debugging only). What is sizeof(uint) in your environment? Increasing the buffer size will certainly solve (or at least work around) the problem. Yet what surprised me is that flag values > 3 really could be meaningless. Note that they are not taken into account in the switch statement to follow. Hence I wonder what is going on in the hash machinery itself. Including why the closing tte_ScoreFlag() operation in ProbeHash() masks the hash flag with 0x07. I mean, it might as well be that this mask value should actually be equal to 0x03.... This would render a meaningful value and explain the buffer size of 4 uints at the same time! Cheers, Joost. > > > -----Ursprüngliche Nachricht----- > Von: Joost 't Hart [mailto:joost.t.h...@planet.nl] > Gesendet: Sonntag, 2. Januar 2011 12:41 > An: Gerd Lorscheid > Cc: scid-users@lists.sourceforge.net > Betreff: Re: [Scid-users] PGN window unstable > > On 01/01/2011 10:58 PM, Gerd Lorscheid wrote: >> Hello again, >> >> in engine.cpp there are the lines: >> >> scoreFlagT hashflag = ProbeHash (depth,&hashscore,&hashmove, >> &isOnlyMove); >> ProbeCounts[hashflag]++; >> >> ProbeCounts is an byte-array of four fields, but hashflag returns values> >> 3. ProbeCounts seems obviously to be used only for debugging purposes. >> Compiled with optimizing the language variable is 18 bytes behind >> ProbeCounts, so there is a major discrepancy between expected and real >> value. > Hi Gerd, > > I never spotted this instability in my windows builds, but you are right. > The same occurs obviously under Linux (but with different symptoms, this > problem must have been there for ages...). > Simplest way to reproduce is to put the pgn cursor somewhere in the game > and than let the internal engine do its job by hovering the mouse over > the board. I added an "assertion" between the quoted statements above. > It fired most of the time with hashflag equal to 6. Both on Windows and > Linux. > > Note that ProbeHash() will never return a value> 7. So I guess that > ProbeCounts[] must be resized to 8 uints. > > Note that the overflow you spotted can have any side effect. But I guess > the language variable change that you saw cannot be a direct result of > the overflow, as 18 bytes is just too far away. Isn't it? > > Cheers, > Joost. > >> I will prepare a patch to clean this up. >> >> Gerd >> >> >> -----Ursprüngliche Nachricht----- >> Von: Gerd Lorscheid [mailto:gerd.lorsch...@onlinehome.de] >> Gesendet: Samstag, 1. Januar 2011 22:05 >> An: scid-users@lists.sourceforge.net >> Betreff: [Scid-users] PGN window unstable >> >> Hello, >> >> the scid binary I am compiling for myself with VisualStudio and optimizing >> enabled likes to crash when I navigate through a game with variations and >> then click on a move in the pgn window. >> What I found is that the global language variable is overwritten by the >> engine code. Next the localization of a move failed by a null pointer, >> because the language and so the offset to the conversion table does not >> exist. The known problem is that the behavior can be different, if > compiled >> with different optimizing options or with a different compiler. But I am >> still interested if anybody has or had the same experiences, because with > a >> future version somebody else can run into the same trouble. >> The engine is allocated and runs for some time before it is deleted. > During >> its run it does not allocate memory, nothing runs in parallel. So this > looks >> like the engine is guilty, but I am not sure about TCL whether something > can >> be triggered in parallel. >> >> Hints are welcome, >> >> Gerd >> >> >> -----Ursprüngliche Nachricht----- >> Von: Benoit St-Pierre [mailto:benbon...@gmail.com] >> Gesendet: Samstag, 1. Januar 2011 18:34 >> An: scid-users@lists.sourceforge.net >> Betreff: Re: [Scid-users] copying games from scid - ctrl-c does not work > as >> expected >> >> Alexander completed my sentence: >> >>> If the game list window is active, copying the active game. >> It copies the active game in the Clipboard. Perhaps this is what we >> would like Scid to do in every context. >> >> When I am in the Database Manager Window, I can click on the Clipbase >> and do stuff. For instance, I can drag the games into another DB. >> >> But it seems I can't easily copy the games from the Clipbase into the >> buffer. That's something I'd like to do when I right-click on the >> Clipbase Icon. (Being able to Open a databse with the right-click is >> a bit strange, btw.) >> >> In fact, lots of actions could be done when right-clicking on this >> icon. Empty Clipboard and Reset filter are very powerful. If I could >> Copy all the Clipbase games into my buffer, that would be great for >> editing purposes. >> >> Whatever comes out of right-clicking, there seems to be a need to >> speed things up with the Exporting Tool. >> >> > ---------------------------------------------------------------------------- >> -- >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, >> and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Scid-users mailing list >> Scid-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/scid-users >> >> >> > ---------------------------------------------------------------------------- >> -- >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, >> and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Scid-users mailing list >> Scid-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/scid-users >> >> >> > ---------------------------------------------------------------------------- > -- >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, > and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Scid-users mailing list >> Scid-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/scid-users >> > > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
