bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %destructor and stack overflow


From: Marcus Holland-Moritz
Subject: Re: %destructor and stack overflow
Date: Wed, 27 Apr 2005 21:20:55 +0200

On 2005-04-27, at 01:55:22 +0200, Hans Aberg wrote:

> At 00:09 +0200 2005/04/27, Marcus Holland-Moritz wrote:
> >On 2005-04-26, at 23:46:10 +0200, Hans Aberg wrote:
> >
> >>  Again, this is probably a question for Paul to answer, who wrote the
> >>  current C-parser. I thought that the C-parser was dynamic, except
> >>  when free store runs out, in which case one is toast anyway. What
> >
> >Yes, it is dynamic. Up to YYMAXDEPTH.
> >
> >Besides, I don't think that anyone will ever get the parser
> >to exhaust its stack. But my test suite checks the "parser
> >overflow" error and that test will leak memory if any stray
> >objects aren't cleaned up. Which is bad for the memory leak
> >checker...
> 
> Why don't you define YYMAXDEPTH to the MAXINT or something? Then you 
> can only get overflow by memory running out.

Ok, let me try to explain my point once more.

I don't need any sort of "workaround". There's no problem that
I need to solve quickly. The current solution I have is fine,
I just like to replace it with something better if possible.

%destructor looks like it has the ability to be this "something
better", but IMO it currently isn't as good as it could be (i.e.
it is worse than my solution with regard to potential memory
leaks arising from parser stack overflow).

I am aware of the fact that if the parser stack blows up, there's
no way to parse the code. Fine. But at least in my application
that isn't much different from a syntax error, since it's just
reported to the user as an error. He can try to fix his code,
and run the parser again. And again. And again. This doesn't
mean he shuts down the application in between. For example, one
of my applications has an editor where you can enter code and
press a button to "compile" the code, which will be carried out
by the module using the bison parser. The user can hit "compile"
a million times. Even though it is extremely unlikely that he
writes code that blows the stack, I don't want the module to
leak memory, especially if it's possible to avoid it.

I think #define'ing YYMAXDEPTH to MAXINT (or any other XXL number)
isn't a good idea. I know that no sane code requires the parser
stack to be as large as 1000 items. So with YYMAXDEPTH = 10000
I'm clearly on the safe side. And I prefer to have an error at a
well-defined boundary rather than some part of the application
running out of "real" memory when passed illegal input.

My point is that I think bison's %destructor behaviour could
be extended to all error cases where a cleanup of the stack is
possible, and I think the parser stack overflow is such an
error case. Unless someone can tell me why it is not possible
or why it should not be done.

> >  > parser stack dynamic reallocation, and gets stack overflow, how do
> >>  you intend to recover. I mean, then the parser cannot handle the
> >>  input semantics properly anyway.
> >
> >Sure. I don't want to recover. I just don't want to leak
> >memory. As I mentioned, the parser is embedded in a Perl
> >module, and the module shouldn't leak memory as the code
> >using the module may run for long periods of time.
> 
> There I do not see exactly what you need. Perhaps Paul can help.

To quote the bison docs:

  "Basically, during error recovery, embarrassing symbols already
  pushed on the stack, and embarrassing tokens coming from the rest
  of the file are thrown away until the parser falls on its feet.
  If these symbols convey heap based information, this memory is
  lost. While this behavior is tolerable for batch parsers, such as
  in compilers, it is unacceptable for parsers that can possibility
  "never end" such as shells, or implementations of communication
  protocols.

  The %destructor directive allows for the definition of code that
  is called when a symbol is thrown away."

So, %destructor _is_ what I need. It's bison's built-in facility
to avoid memory leaks. All I'd like to see is that the existing
functionality is extended to the parser stack overflow case.

Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]