On Thu, 25 Aug 2005, Paul Eggert wrote: > Thanks for mentioning this. However, I'd rather not complicate > all the skeletons for the sake of this GLR-specific problem.
In my approach, "c.m4" required only a two line addition that made yydestruct() safer anyway, but that was about it. As I pointed out, the one line change to yysymprint() wasn't really required. However, I like your patch because... > I installed the following patch instead. It outputs a bit more > information than the patch you proposed, since it mentions which > popped items were unresolved. Please let me know how it works for you. The extra information is helpful. > On Wed, 24 Aug 2005, Joel E. Denny wrote: > > 3. Although my patch prevents the potential seg fault, I believe there's > still a potential memory leak that it does not address. That is, if > !yyresolved, the yyGLRState stores a list of yySemanticOption's. Each > yySemanticOption has a yystate member. That yystate is the last state in > a RHS potentially containing many semantic values. For this case of an > error during a split stack, I cannot find where the user destructors are > called for those semantic values. Based on the `well-formed' comment at > `yyreturn:', I wonder if this might be a conscious decision. I'll > continue to explore this, but does anyone already know what's going on? I was almost done with a patch to this problem when I saw your patch. I'm glad to see you created yydestroyStackItem(). I had already created a similar function in my new patch. Once I update it for your version of the function, I'll post it. It'll probably be later today. Joel
