Re: [Bug-gnubg] Crash during play

[Jim Segrave]

On Fri 29 Nov 2002 (12:21 +0100), Nardy Pillards wrote:
> > > 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?
> 
> br1.c (win32, cvs 021128) is posted here (zipped):
> http://users.skynet.be/bk228456/br1.zip
> (1.5 MB)

I've got a bad feeling about this:
I assume, again, I haven't looked deeply into the code, that gnubg
either doesn't use the first 40 entries of the database, which appear
to be filled with an ID string. But...

Under Unix we have:

static unsigned char acBearoff1[] = { 
   0x67, 0x6E, 0x75, 0x62, 0x67, 0x2D, 0x4F, 0x53, 
   0x2D, 0x30, 0x36, 0x2D, 0x31, 0x35, 0x2D, 0x31, 
   0x2D, 0x31, 0x2D, 0x30, 0x78, 0x78, 0x78, 0x78, 
   0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 
   0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x0A, 
   0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 

Which is 'GNUBG-OS-06-15-1-1-0xxxxxxxxxxxxxxxxxxx\n'

And the Windows version has:
static unsigned char acBearoff1[] = { 
   0x67, 0x6E, 0x75, 0x62, 0x67, 0x2D, 0x4F, 0x53, 
   0x2D, 0x30, 0x36, 0x2D, 0x31, 0x35, 0x2D, 0x31, 
   0x2D, 0x31, 0x2D, 0x30, 0x78, 0x78, 0x78, 0x78, 
   0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 
   0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x78, 0x0D, 
   0x0A, ...

Note the extra \r in this output, which will move the whole database
off by one byte. This will also kill every other occurence of 0x0a
everywhere in the database (15432 times). I suspect this is not
desireable behaviour. 

makebearoff attempts to avoid this by trying to fdopen stdout in rb
mode, but it appears this isn't working. I've checked in a version of 
makebearoff which adds a -f <filename> option. This will be opened in
"rb" mode, so it should produce UNIX line endings under Windows. The
makefile line 

    makebearoff -o 6 -s 7999999 > temp.bd

should become

     makebearoff -o 6 -s 7999999 -f temp.bd

When run, the start of br1.c should look like the Unix version - the
6th line of the array should start with 0x00, not 0x0A.


-- 
Jim Segrave           address@hidden