Re: bison and valgrind
- From: "Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: 30 Mar 2007 05:30:20 GMT
Allan Adler wrote:
I found that bison
doesn't complain if I change it to something like:
{$$ = cat_gleep($1,$2);
free_gleep(&$1);
free_gleep(&$2);
}
Of course, not. Bison is a parser generator. It has no interest in
the semantic content of your parse actions. You could do
(for i = 0; i < 10000; i++)
malloc(1000);
in there if you wanted -- it's no part of Bison's job to prevent, or
even help diagnose, that.
If you want automatic storage management (which I think you /should/
want) then you know where to find it ;-)
That probably means that I do have a little bit of control over leaks.
It would be fairer to say that you can choose whether to introduce
leaks or not. Nothing to do with Bison.
When I ran valgrind, I found that there were leaks in the routines
yy_flex_alloc and yy_create_buffer. I'm less certain about how to deal
with these, since it appears that they come from the boiler plate of
flex (I don't really know for sure).
I find it hard to believe that there's a leak in Flex as the term is
normally understood. It may well be that there's a one-off allocation
that is never released (which is normal and unsurprising, even though
it may be unacceptable for your application). But if Flex-generated
scanners leak a certain amount of memory on every call (or in some
other pattern which means that Flex can leak an unbounded amount of
memory over a program's lifetime) then I'd be more than a little
surprised. And it would be a bug well-worth fixing, so I don't think
you'd have difficulty persuading the Flex maintainers to adopt a fix.
-- chris
.
- References:
- bison and valgrind
- From: Allan Adler
- Re: bison and valgrind
- From: Allan Adler
- bison and valgrind
- Prev by Date: Re: Combination of binary variables
- Next by Date: Re: A (psossibly) fast, novel search table technique
- Previous by thread: Re: bison and valgrind
- Next by thread: Re: bison and valgrind
- Index(es):
Relevant Pages
|
