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