[Bug-gnubg] Core dumps during rollouts

[Jim Segrave]

On Mon 02 Dec 2002 (21:17 +0100), Jim Segrave wrote:
> On Mon 02 Dec 2002 (17:01 +0100), olivier croisille wrote:
> > Hi,
> > 
> > 2-ply untruncated roll outs are way too slow, so I personnally like 1-ply 
> > roll outs.
> > 
> > I experience a pb in this respect, as GNU systematically crashes right away 
> > when launching a move or cube decision roll out with following settings:
> > 
> > - 360 games
> > - 'enable separate...' : off
> > - no truncation
> > - cubeful : on
> > - var red : on
> > - rotate : on
> > - 'cube decisions...' : on
> > - 'use same settings...' : on
> > - 'use player...' : on
> > 
> > ...and finally, the setting that causes the crash apparently (otherwise 
> > works perfectly well with 'expert' for instance, or even 2-ply, eventhough 
> > awfully slow) :
> > 
> > 1-ply, medium search space, cubeful checker eval
> > 
> > Comments welcome, and congrats, as always, for the brilliant piece of 
> > software
> 
> I can reproduce this, so I'll start poking at the corpse with gdb. 
> It's core dumping on a pointer deref. 

OK - I know what the problem is, but I don't know what the right fix
is. This is a consequence of the movefilter changes (and interaction
with the existing code):

The above rollout settings have a maxiumum search candidates of 4 in
the eval context.

FindBestMovePlied sets up local stack space for a move list:

  int i, iPly;
  movelist ml;
#if __GNUC__
  move amCandidates[ pec->nSearchCandidates ];
...

which means amCandidates can hold 4 moves at most. One ply filters
accept a maximum of 8 moves. These are copied to amCandidates, with
the expected results, The movelist ml, above before the copy:
(gdb) p ml
$14 = {cMoves = 29, cMaxMoves = 2, cMaxPips = 5, iMoveBest = 0,
  rBestScore = 1.23403072, amMoves = 0x8285360}

and now after the copy:

(gdb) p ml
$20 = {cMoves = 5, cMaxMoves = 1063492118, cMaxPips = 1065160004,
  iMoveBest = 1061489696, rBestScore = 0.457899898, amMoves = 0x2}

This code needs to change to allocate enough space for the maximum
number of candidate moves, which depends on the movefilter being
used. I'm not sure what the right fix for this is, but this is
currently very broken whenever the evalcontext setting for maximum
candidates is less than the movefilter value.



-- 
Jim Segrave           address@hidden