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). _______________________________________________ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison