Re: memory leak

[Hans Aberg]

At 09:49 +0100 2001/02/20, Olivier Dwelshauvers wrote:
>> I'm not surprised actually.  Also, AFAIK, Bison offers no means to
>> release the memory associated to symbols shifted during error
>> recovery.
>
>The memory leaks I noticed appear in normal execution, not in error
>recovery. I just wrote a main() which loop on yyparse(), opening and
>closing the input each loop.
>Every ten loops it print the result of :
>         system("ps -ef -o pid,vsize,rssize,command | grep -e PID -e
>prg_name");
>That's how I could point the problem.

I had a look at the parser my Bison invokation writes, and it uses
statically allocated stacks only. (For dynamically allocated stacks one has
to write some stack allocation functions it seems.) There is no other
dynamic memory allocation, except for some error message strings, but those
are properly freed immediately after the error message has been output.

As for other memory leaks, it seems me the only safe way is to compile
under C++, and write classes that do proper memory allocation/deallocation.
Thus
  class my_type {
  public:
    A* ap; // Pointer should have proper deallocation within class.
    B b;   // Or use automatic (stacked) elements.

    my_type() : ap(0) { }
    ~my_type() : { delete ap }

    my_type(A* ap) : ap(ap) { }  // pointer must be created using "new"
  };

  #define YYSTYPE my_type

If you do not have this destructor ~my_type() within the class, then my
guess it is going to be hard to avoid memory leaks with the parser that
Bison writes.

How is your program structured? That is, do you have such class external
memory allocations that are not cleaned up by the class itself?

  Hans Aberg