[Bug c/21879] Memory management problem in new C parser

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joseph at codesourcery dot com  2005-06-02 19:08 -------
Subject: Re:  Memory management problem in new C parser

On Thu, 2 Jun 2005, ebotcazou at gcc dot gnu dot org wrote:

> Do you mean that parser_obstack is effectively a per-toplevel-decl object and
> that it is supposed to be dead at the end of the object's parsing, although in
> the present case there are objects associated with different toplevel decls
> allocated on it that point to each other?  And I presume label_context_stack_vm
> is not explicitly reset to NULL on function exit because of nested functions?

Yes, the parser obstack contains objects with varying lifetime but all of 
them should be dead at the end of a toplevel decl, so it is freed at the 
end of each such decl.  There should never be objects associated with 
different toplevel decls on it, because everything that can point into it 
should be NULL at the end of such a decl.  (Various structures that can 
point into it are in variables in other files, such as these lists of 
labels and lists of decls used inside sizeof or typeof; declarators and 
associated structures also live on it but should mostly only be pointed to 
from local variables.)

Yes, nested functions mean it is not reset to NULL on function exit - and 
because GNU extensions allow a nested function to refer to explicitly 
declared labels in the containing function, it isn't clear that using the 
function context for this (resetting to NULL on function entry and 
restoring on exit; we do always have matched push_function_context / 
pop_function_context pairs for nested functions even with parse errors) 
would be right either.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21879