Re: %destructor and stack overflow

[Marcus Holland-Moritz]

Hi Hans,

thanks for the quick response!

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

My current keep-unreferenced-objects-in-lists method handles
the overflow without any leaks, and I'd like to keep that
behaviour if I switch to using %destructor.

> version of Bison are you using? Is it Bison 2.0? If you have disabled 

Yes, Bison 2.0.

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

Marcus


> At 22:39 +0200 2005/04/26, Marcus Holland-Moritz wrote:
> >Hi,
> >
> >I've been using bison for the C parser in one of my perl modules for a
> >couple of years now. (http://search.cpan.org/~mhx/Convert-Binary-C/)
> >
> >I recently noticed the %destructor feature and it looks as it would solve
> >a problem that has long been on my todo list. Right now I'm collecting
> >all objects that I don't reference otherwise in various lists so I can
> >free them when the parser exits (when it exits normally, the lists are
> >usually empty). However, maintaining these lists is time-consuming (both
> >in programming time and execution time).
> >
> >I've now rewritten my parser to make use of %destructor, and it works
> >fine generally. The only case where it doesn't work is when a parser
> >stack overflow is detected. I can see from the generated parser code
> >that a parser stack overflow error bypasses yydestruct().
> >
> >My question: Is there a reason why the %destructor code isn't called
> >upon parser stack overflow?
> >
> >I don't see a reason, because when the stack overflow is detected,
> >the whole stack is still valid and even the items about to be pushed
> >on the stack are valid and known to the parser. So it should at least
> >be possible to do a correct cleanup of the parser stack.
> >
> >Thanks,
> >Marcus
> >
> >--
> >One of the most overlooked advantages to computers is...  If they do
> >foul up, there's no law against whacking them around a little.
> >             -- Joe Martin
> >
> >
> >_______________________________________________
> >address@hidden http://lists.gnu.org/mailman/listinfo/help-bison