Memory leaks upon error recovery in Yacc

"David Pereira" <>
18 Nov 2000 00:55:16 -0500

          From comp.compilers

Related articles
Memory leaks upon error recovery in Yacc (David Pereira) (2000-11-18)
Re: Memory leaks upon error recovery in Yacc (Timur Safin) (2000-12-01)
Re: Memory leaks upon error recovery in Yacc (2000-12-18)
Re: Memory leaks upon error recovery in Yacc (2000-12-18)
| List of all articles for this month |

From: "David Pereira" <>
Newsgroups: comp.compilers
Date: 18 Nov 2000 00:55:16 -0500
Organization: Excite@Home - The Leader in Broadband
Keywords: yacc, errors
Posted-Date: 18 Nov 2000 00:55:16 EST

I am building a syntax tree with Bison, using the following
method. For example,

expr: expr '+' expr { $$=malloc(sizeof (binary_node_t));
                $$->left = $1; $$->right =$2; $$->op = PLUS; }
        | NUM { $$=malloc(struct (int_node_t)); }

Plain and simple. Just a tree of allocated nodes.

The problem is error productions. When an error occurs, the yacc/bison
parser pops state/semantic-value pairs off the top of the stack until it
reaches a state whose underlying set of items contains the error keyword.
(No problem here, this is standard yacc style error recovery). This
introduces a problem, however, because those semantic values popped off the
stack, can contain pointers to subtrees, that would have been integrated
into a bigger subtree, had the parse gone smoothly at that level. Therefore,
I have memory leaks and I would like to deallocate those subtrees. One
solution is to wrap malloc () with something like FOOMALLOC () that adds the
pointer to every node it allocates into a list. That way, at the END of the
parse I can blow away all nodes in that list that are not part of the syntax
tree. BUT, I want to do this memory reclamation RIGHT AFTER each error
production has kicked in (I don't want to wait till the parse has finished).

[You can try to free memory by using error rules to avoid the implicit
pops, but this is definitely one of yacc's weaker areas. -John]

Post a followup to this message

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