Re: bison and valgrind

On Mar 30, 5:24 am, Allan Adler <a...@xxxxxxxxxxxxxxxxxxxx> wrote:
Allan Adler <a...@xxxxxxxxxxxxxxxxxxxx> writes:
I haven't actually tested the parser with valgrind. I'll do that tomorrow.
I just consider it extremely likely that it will be leaky.

I did it. As I expected the parser is leaky. Let's call the data type a gleep.
When the action says {$$ = cat_gleep($1,$2);}
thereby causing a new gleep to be allocated, I found that bison doesn't
complain if I change it to something like:
{$$ = cat_gleep($1,$2);
free_gleep(&$1);
free_gleep(&$2);

}

Yes. Bison has no interest in the C in your actions, you can write
leaks in that to your hearts content.

An easy way to solve the above problem is to write your own allocator
for your parser. What you do is to allocate say 16kb for parser
info. You use this to build the tree then you can write a routine
that frees all memory associated with your special allocator when you
have finished with the tree.

GC is the best way though.

not.. Assuming I can do that, what I am then worried about is that the place
where I have to modify the parser to plug the leak will be part of the boiler
plate code that bison uses, and therefore is not really accessible as part of
the normal use of bison and flex. In particular, if I modify the .y file, I
will also have to modify by hand the file that bison produces every time I do
so. There are worse fates, but if there is a way to avoid this particular
fate, I'd like to know about it.

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).

Flex uses one buffer for the characters taken from the stream it's
parsing. I think it expands this buffer as needed, to the length of
the longest token, and never shrinks it. This isn't really a leak,
but valgrind will consider it one.

.

Relevant Pages

  • bison and valgrind
    ... I've made some progress and have managed to use bison and flex to write ... One of the things I did to avoid leaks was to use valgrind. ... What I'm worried about is that the parser might have a lot of leaks. ...
    (comp.programming)
  • Csup cvsmode build discussion
    ... lex and yacc files that I would like to discuss. ... I implemented the RCS parser required to operate on RCS files ... I've been compiling the parser and tokenizer with the help of bison ... Now, the base system already have flex, but the flex version in base is heavily ...
    (freebsd-hackers)
  • Re: Csup cvsmode build discussion
    ... lex and yacc files that I would like to discuss. ... I implemented the RCS parser required to operate on RCS files ... I've been compiling the parser and tokenizer with the help of bison ... Now, the base system already have flex, but the flex version in base is heavily ...
    (freebsd-hackers)
  • Re: Flex&Bison: how to write a parser for this grammar?
    ... bison? ... it's better to rely on a parser generator than on hand-written ... a yacc parser will be simpler if the grammar is suitable so ... need for flex start conditions there as I feared there might be. ...
    (comp.programming)
  • ANNOUNCE: DJGPP port of GNU bison 2.1 uploaded.
    ... This is a port of GNU Bison 2.1 to MSDOS/DJGPP. ... Bison is a Yacc compatible parser generator. ... Bison 2.1 is mostly a bug fix version since the last official release ... If LFN support is available or not is determinated at run time. ...
    (comp.os.msdos.djgpp)