Re: Memory leak in flex generated file

George Neuner <gneuner2@comcast.net>
23 Oct 2005 00:35:06 -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)
Re: Memory leak in flex generated file johnmillaway@yahoo.com (John Millaway) (2005-10-27)
Re: Memory leak in flex generated file johnmillaway@yahoo.com (John Millaway) (2005-10-29)
[2 later articles]
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: 23 Oct 2005 00:35:06 -0400
Organization: Compilers Central
References: 05-10-140
Keywords: tools
Posted-Date: 23 Oct 2005 00:35:06 EDT

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


>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.
>
<snip huge listing>


It's possible the verifier tool is misleading you - Flex makes some
allocations the first time it is called which will be reused by
subsequent calls. If you haven't created a reentrant scanner, those
allocations will be global and valgrind might be considering them to
be a leak.


OTOH,
I haven't used either Flex or Bison for a while, but in the past they
had a number of ways to leak memory. Flex had several issues related
to buffering which made it problematic to use multiple input streams
or to scan input from memory rather than from traditional files. When
used with the %pure_parser option Bison's own memory use was sound,
but when a parse error occurred any scanner allocations made for the
unmatched tokens would be lost.


I used Flex and Bison to scan input from memory in an embedded system
where no leaks could be tolerated. I ended up manually controlling
Flex's buffering and reading, and using a custom allocator to
guarantee that any dangling allocations would be freed in the event of
a parse failure.


George


Post a followup to this message

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