Frank Heckenbach wrote:
Waldek Hebisch wrote:
Line numbers point into Bison parser. I did some more investigation, it seems that parser stack overflows and couses crash. I think I have found bison bug: in some cases Bison fails to check if stack is not full. When I decrease stack size I can get crashes in the testsuite. Still, it would be nice if you can confirm my findings by printing the above values.
Investigating Chief's report I have found that GPC parser may crash due to undetected parser stack overflow. To avoid the problem you can either apply the following patch to `parse.c' or patch `parse.y' and `glr.c' from bison distribution. The second way is "better", but requires you to have bison-2.1 and to patch its installotion.
Did you report it to the Bison developers, or should I? (I'm subscribed to the bug-bison list.) Do we have an easy to reproduce Bison example? (The GPC parser might be a bit complex for this purpose. ;-) If not, perhaps the change will be obvious enough to them. Did you check whether other places in glr.c are affected as well (as you said "some cases" above), or only this one?
I have sent the following (+ the patch) to Bison bug address:
: bison-2.1 fails to detect stack overflow in GLR parser. Namely, : `yyglrShiftDefer' assumes that there are 2 free stack slots, and : check is done only in `yyaddDeferredAction'. However, `yyexpandGLRStack' : only guaranteed increase by one. The problem appered in GNU Pascal, : causing segmentation faults due to parser stack overflow. I do not : include a testcase since GNU Pascal parser is large.
"some cases" mean that the bug is triggered only on some inputs, on different inputs stack overflow is detected. I belive that the patch completly fixes the problem. I just got a message from Paul Eggert saying that he installed slightly modified patch. So the problem should be fixed in Bison 2.2.