Re: Leaks from bison 2.0/Flex 2.5

[Hans Aberg]

On 3 Oct 2005, at 08:23, Tim Van Holder wrote:

> > I've managed to get the parser & scanner generated from Bison &  
> > Flex to leak
> > -- and not from my own actions. I don't know whether it is caused  
> > by me using 
> > them in a wrong way, or because Flex and/or Bison contains bugs.  
> > Below
> > comments have as background Bison 2.0, Flex 2.5.4, and valgrind  
> > 3.0.1.
> >
> > ==21666== 1725 bytes in 41 blocks are definitely lost in loss  
> > record 170 of
> > 202
> > ==21666==    at 0x1B8FEA7B: malloc (vg_replace_malloc.c:149)
> > ==21666==    by 0x1BB2C225: XPathparse(KXPATH::ParserInformation*)
> > (XPathParser.tab.cpp:2174)
>
> I don't remember seeing this one before; either it's one that was
> introduced in a recent release, or you're using the lalr1.cc
> skeleton (although that seems unlikely as this is a plain malloc
> call).  I'd suggest looking at line 2174 of XPathParser.tab.cpp to
> see what is being allocated, and where it's used - that might suggest
> a cause for the leak.

This leak is due to the allocation of a C-string for error messages.  
The leak can be fixed by using std::string instead (which I did in  
the skeleton file I am using).

Bison and Flex are designed to just run as a program in one go, in  
which case leaks will be recovered when the program terminates. In  
such a use, they are probably not significant enough to be fixed, I  
think, even though it would be more pleasing.

  Hans Aberg