Re: [Bug-gnubg] Crash during play

[Jim Segrave]

On Fri 29 Nov 2002 (08:30 +0000), Joern Thyssen wrote:
> On Thu, Nov 28, 2002 at 04:44:52PM +0100, Holger wrote
> > At 16:02 28.11.2002 +0100, Holger wrote:
> > >At 23:49 27.11.2002 +0100, ?ystein Johansen wrote:
> > >>>===== Original Message From "Nardy Pillards" <address@hidden>
> > >=====
> > >>>> I've just tried my newly built version. But it crashes.
> > >>>>
> > >>>> I start a 1-pt-match, and at some point when GNUbg thinks about its 
> > >>>> move
> > >>>or
> > >>>> cube decision it crashes.
> > >>>> Attached is a match where, after playing 12-6 8-3 in the following 
> > >>>> move,
> > >>>> the program crashes.
> > >>>> This has happened not only in this match but all (only 3) with this
> > >>>version.
> > >>>>
> > >>>> Win2k, CVS checkout a few minutes ago. (27.11.02 19:30 German time) 
> > >>>> Last
> > >>>> commit is from Jim: "Cosmetics to suppress compiler warnings".
> > >>>>
> > >>>> So, either I did something wrong during compilation, or there is a bug.
> > >>>> Holger
> > >>>
> > >>>Doesn't crash on my PC (WinME, same CVS)
> > >>
> > >>As I'm trying Nardys build on a Win2000 system: I crashes in race
> > positions. 
> > >>Everything else seems to work nice.
> > >
> > >I've tried it with Nardy's build (021127) now, too. Same result.
> > >I didn't realize before that it were always positions when the contact was
> > >lost.
> > 
> > With the current CVS (28..11.02 16:30) it also still crashes.
> 
> Since it crashes on race positions there might be a problem with the new
> bearoff databases (gnubg uses bearoff databases for calculating bg
> chances; also multiple ply may reach bearoff database). 
> 
> Has anybody been able to reproduce the problem on un*x? Especially
> interesting is Jim's BSD since the memory handling is different on those
> boxses, so any possible memory problem would be more likely to show up
> there.

So far I've tried the posted matches and have been able to play out
the games without incident.

I've not looked at the code, so this could be wildly wrong, but all
the reports of make doing odd things when building br1.c make me
wonder.

If br1.c doesn't have the complete output from makebearoff compiled in
(e.g. it stops with some number of entries not supplied), will the
code behave properly or will it assume that there is data present when
there actually is not?


-- 
Jim Segrave           address@hidden