Bison, memory leaking

Dennis Bj|rklund <md3den@mdstud.chalmers.se>
25 May 1997 12:47:03 -0400

          From comp.compilers

Related articles
Bison, memory leaking md3den@mdstud.chalmers.se (Dennis Bj|rklund) (1997-05-25)
Re: Bison, memory leaking cef@geodesic.com (Charles Fiterman) (1997-05-27)
Re: Bison, memory leaking pfox@lehman.com (Paul David Fox) (1997-05-27)
Re: Bison, memory leaking md3den@mdstud.chalmers.se (1997-06-02)
Re: Bison, memory leaking sam.ravnborg@image.dk (1997-06-04)
| List of all articles for this month |
From: Dennis Bj|rklund <md3den@mdstud.chalmers.se>
Newsgroups: comp.compilers
Date: 25 May 1997 12:47:03 -0400
Organization: Compilers Central
Keywords: yacc, errors, comment

There is a problem with bison. When bison tries to fix a parse error
then it discards semantic values on the valuestack and it discards
tokens that it gets from yylex(), until it reaches a state that it can
reduce in.


The problem is that if you have dynamicly allocated data in the
semantic value. Then it is lost. And we have a memory leak. And very
often you have some dynamic data there. (A tree, a linked list, C++
objects with destructors, or ...).


I have pretty much solved the problem by adding some stuff to the
parser. basicly a function-call that is called when the parser
discards a semantic value. (I call it yydiscard). Here the
parser(writer) can examine which symbol is discarded and
deallocate the semantic value.


I can however not use bison as it is. I need a little different output.
I need the yystos table and some defines of the nonterminal and terminal
symbols (the internal numbers, called NTxxx and Txxx in bison).
But bison only emits these if you have a %semantic_parser.


I can fix it myself just for me (already done that). But I think that
more people then I should be interesting in this.


And why isn't there anything done in this area before?


And where can I get in touch with the person who works with bison.


/Dennis (md3den@mdstud.chalmers.se)
[This is a well-known yacc problem. I usually solve it by chaining the
malloc'ed data together and then releasing it all either at the end of
the parse or in the top-level statement-list type rule. -John]
--


Post a followup to this message

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