Re: Leaks from bison 2.0/Flex 2.5

[Tim Van Holder]

Frans Englich wrote:
> Hello,
> 
> 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.

> ==21666== 86689 (45560 direct, 41129 indirect) bytes in 1139 blocks are 
> definitely lost in loss record 197 of 202
> ==21666==    at 0x1B8FEA7B: malloc (vg_replace_malloc.c:149)
> ==21666==    by 0x1BB2F0A9: yy_flex_alloc(unsigned) (lex.XPath.c:2148)
> ==21666==    by 0x1BB2EEAE: XPath_scan_buffer(char*, unsigned) 
> (lex.XPath.c:1944)

This one is standard lex behaviour - on first call to yylex(), it
allocates a buffer, which it then continues using throughout its
lifetime.  Since there is no yy_shutdown_lex() function, it never has
the opportunity to free this buffer itself, and it will show as a leak
in valgrind.
In your particular case, however, it is your own doing - you call
yy_scan_string(), which returns a (malloc()ed) YY_BUFFER_STATE.
It is that structure that is being leaked; simply call
yy_delete_buffer() on it to resolve the leak (you should have been
able to find this out yourself from looking at lex's output source
though).