Path: utzoo!utgpu!watmath!watdragon!dahlia!dtsteen
From: dtsteen@dahlia.waterloo.edu
Newsgroups: comp.sys.amiga
Subject: Re: Bison mystery
Keywords: bison out of memory
Message-ID: <14664@watdragon.waterloo.edu>
Date: 22 Jun 89 22:09:34 GMT
References: <14622@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu
Reply-To: dtsteen@dahlia.waterloo.edu ()
Distribution: na
Organization: U. of Waterloo, Ontario
Lines: 41

In article <14622@watdragon.waterloo.edu> I write:

>Recently, I have been playing with Bison and Flex (from Fred Fish disks
>160-170 or thereabouts)...

>...This is from a mini-tutorial on yacc in an AT&T book.  Surprise!  It
>didn't work.  Without an instant's hesitation, Bison reported that it
>was out of memory.  A quick check yielded 650K free, and barely any of
>it touched before the error occurred.

Apparently I was not the only one who noticed this bug.  Well, I found
it and here's the scoop:

Bison uses the calloc() function to obtain its memory.  When the grammar
it processes is very simple, one or more calls to calloc() are made
requesting that it allocate zero bytes of memory.

On Unix this is OK -- each request to allocate zero bytes results in a
valid pointer, and the pointers are all different.  With Lattice C,
a calloc(0,1) returns zero.  This causes Bison to believe that it has
run out of memory, and thus the problem.  Clearly a bug in Bison, but
one which only shows with this particular implementation of calloc().

Fortunately, the fix is easy.  Just make the change below to the file
"allocate.c" and recompile.

  block = calloc(n,1);
  if (block == NULL && n != 0)
                   ^^^^^^^^^^
    {
      fprintf(stderr, "bison: memory exhausted\n");
      done(1);
    }

Note that apart from this but, Bison appears to be a *very* solid port.
I went from initially removing it from its Zoo archive to compiling and
trying several large grammars, totalling four hours or so, without a
single crash or reboot.  We need more programs like this.

Markus Wandel
(519) 884-9669