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. If you do not want to mess with bison patch to `parse.c' should be enough to avoid problems with GPC. Patches to `parse.y' and `glr.c' are in attachement. Both patches increase size of GPC parser stack.
--- ../../../rr/gpc/p/parse.c 2006-02-15 03:05:20.000000000 +0100 +++ parse.c 2006-02-25 14:06:37.639531864 +0100 @@ -287,6 +287,7 @@ /* Copy the first part of user declarations. */ #line 63 "parse.y"
+#define YYMAXDEPTH 200000 #include "gpc.h"
/* A few keywords of some dialects can be parsed as regular identifiers @@ -8277,7 +8278,7 @@ size_t yysize, yynewSize; size_t yyn; yysize = yystack->yynextFree - yystack->yyitems; - if (YYMAXDEPTH <= yysize) + if (YYMAXDEPTH < yysize + YYHEADROOM) yyMemoryExhausted (yystack); yynewSize = 2*yysize; if (YYMAXDEPTH < yynewSize)
On 25 Feb 2006 at 13:43, Waldek Hebisch wrote:
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. If you do not want to mess with bison patch to `parse.c' should be enough to avoid problems with GPC. Patches to `parse.y' and `glr.c' are in attachement. Both patches increase size of GPC parser stack.
--- ../../../rr/gpc/p/parse.c 2006-02-15 03:05:20.000000000 +0100 +++ parse.c 2006-02-25 14:06:37.639531864 +0100 @@ -287,6 +287,7 @@ /* Copy the first part of user declarations. */ #line 63 "parse.y"
+#define YYMAXDEPTH 200000 #include "gpc.h"
/* A few keywords of some dialects can be parsed as regular identifiers @@ -8277,7 +8278,7 @@ size_t yysize, yynewSize; size_t yyn; yysize = yystack->yynextFree - yystack->yyitems;
- if (YYMAXDEPTH <= yysize)
- if (YYMAXDEPTH < yysize + YYHEADROOM) yyMemoryExhausted (yystack); yynewSize = 2*yysize; if (YYMAXDEPTH < yynewSize)
Problem solved :). Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
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?
Frank
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.
Waldek Hebisch wrote:
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.
Yes, I saw it.
"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.
OK, thanks.
Frank
-
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief) -
Waldek Hebisch