Memory leak in flex generated file

"pavel.orehov@gmail.com" <pavel.orehov@gmail.com>
20 Oct 2005 00:14:55 -0400

          From comp.compilers

Related articles
Memory leak in flex generated file pavel.orehov@gmail.com (pavel.orehov@gmail.com) (2005-10-20)
Re: Memory leak in flex generated file haberg@math.su.se (2005-10-23)
Re: Memory leak in flex generated file gneuner2@comcast.net (George Neuner) (2005-10-23)
Re: Memory leak in flex generated file johnmillaway@yahoo.com (John Millaway) (2005-10-26)
Re: Memory leak in flex generated file Markus.Elfring@web.de (2005-10-26)
Re: Memory leak in flex generated file haberg@math.su.se (2005-10-27)
Re: Memory leak in flex generated file haberg@math.su.se (2005-10-27)
[4 later articles]
| List of all articles for this month |

From: "pavel.orehov@gmail.com" <pavel.orehov@gmail.com>
Newsgroups: comp.compilers
Date: 20 Oct 2005 00:14:55 -0400
Organization: http://groups.google.com
Keywords: lex, question, comment
Posted-Date: 20 Oct 2005 00:14:55 EDT

Hi,


I did not found flex/bison group, so i put it here.


I am using flex and bison to parse HTTP headers. After some
investigation i found a memory leak in flex generated file with
valgrind tool.


Does anybody meet this leak problem or i am a bad user ?


Here is the valgrind log:


==============================================================
==18981== Memcheck, a memory error detector for x86-linux.
==18981== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et
al.
==18981== Using valgrind-2.2.0, a program supervision framework for
x86-linux.
==18981== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et
al.
==18981==
==18981== My PID = 18981, parent PID = 4585. Prog and args are:
==18981== http_parser
==18981== req_header
==18981== 1
==18981== For more details, rerun with: -v
==18981==
==18981== Invalid read of size 1
==18981== at 0x1B906791: strlen (mac_replace_strmem.c:189)
==18981== by 0x1B98C4A0: std::string::string(char const*,
std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.7)
==18981== by 0x804BD1B: parse(char const*, ***::HTTP_Header*) (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== by 0x80520B4: main (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== Address 0x1BB344E1 is 0 bytes after a block of size 761
alloc'd
==18981== at 0x1B9072D9: operator new[](unsigned)
(vg_replace_malloc.c:139)
==18981== by 0x8051FDD: main (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981==
==18981== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from
1)
==18981== malloc/free: in use at exit: 6452 bytes in 4 blocks.
==18981== malloc/free: 58 allocs, 54 frees, 100231 bytes allocated.
==18981== For counts of detected errors, rerun with: -v
==18981== searching for pointers to 4 not-freed blocks.
==18981== checked 2405248 bytes.
==18981==
==18981==
==18981== 4 bytes in 1 blocks are definitely lost in loss record 1 of 2
==18981== at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
==18981== by 0x804F226: yyalloc(unsigned) (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== by 0x804EFF7: yyFlexLexer::yyensure_buffer_stack() (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== by 0x804CF85: yyFlexLexer::yylex() (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== by 0x804BC92: yylex() (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== by 0x804AA21: yyparse() (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== by 0x804BE38: parse(char const*, ***::HTTP_Header*) (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981== by 0x80520B4: main (in
/home/***/HTTP_Parser_FBL/http_parser)
==18981==
==18981== LEAK SUMMARY:
==18981== definitely lost: 4 bytes in 1 blocks.
==18981== possibly lost: 0 bytes in 0 blocks.
==18981== still reachable: 6448 bytes in 3 blocks.
==18981== suppressed: 0 bytes in 0 blocks.
==18981== Reachable blocks (those to which a pointer was found) are not
shown.
==18981== To see them, rerun with: --show-reachable=yes


--------------------------------------------------------------
[I think it's deliberate. If you look at the code, it allocates a state stack and never
frees it. Since the state stack is rarely large and is reused on subsequent runs, it's
not a big deal. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.