Re: data/glr.c yyinitGLRStack() (fix)

[Paul Eggert]

address@hidden writes:

> static yybool
> yyinitGLRStack (yyGLRStack* yystack, size_t yysize)
> {
>   yystack->yyerrflag = 0;
>   yystack->yyerrState = 0;
>   yynerrs = 0;
>   yystack->yynextFree = 0;                <------ inits added
>   yystack->yyitems = 0;                   <------
>   yystack->yyspaceLeft = 0;               <------
>   yystack->yysplitPoint = NULL;           <------
>   yystack->yylastDeleted = NULL;          <------

Hmm, I don't see why these initializations are needed; the values
aren't used if yyinitGLRStack returns false.

>   yystack->yynextFree = yystack->yyitems =
>     (yyGLRStackItem*) YYMALLOC (yysize * sizeof yystack->yynextFree[0]);
>   if (! yystack->yyitems)
>     return yyfalse;                       <------ check added

Nor do I see why this check is needed; yyinitGLRStack returns false
eventually anyway.

> static void
> yyfreeGLRStack (yyGLRStack* yystack)
> {
>   if (yystack->yyitems)                  <------ yystack->yyitems can be 0
> at malloc() failure
>     YYFREE (yystack->yyitems);

YYFREE is supposed to behave like free, and free (NULL) is a no-op.
(glr.c can assume C89 semantics.)

> static void yyfreeStateSet (yyGLRStateSet* yyset)
> {
>   YYFREE (yyset->yystates);              <-------- this

Similarly here.

> If simulating malloc() failure doing `return yyfalse;' then segfault:
>
> 48. actions.at:529: testing ...
> actions.at:529: bison -o input.c input.y
> actions.at:529: $CC $CFLAGS $CPPFLAGS $LDFLAGS -o input input.c $LIBS
> stderr:
> stdout:
> actions.at:529: $PREPARSER ./input '(x)'
> --- /dev/null 2004-10-02 10:38:03.000000000 +0200
> +++ /home/gcc/bison/tests/testsuite.dir/at-stderr     2005-07-16
> 15:41:50.725320192 +0200
> @@ -0,0 +1 @@
> +./testsuite: line 904:  8658 Segmentation fault      $PREPARSER ./input

Hmm, I don't get a segfault.  I assume you're using the latest CVS
version?  Which call to YYMALLOC, exactly, did you have return NULL?
(I did the first one.)

However, I did notice a problem in that area, though: yyparse was
returning 0 when the initial YYMMALLOC failed.  I installed this patch
to fix things.  Does it fix your segmentation fault as well?  If not,
can you give a backtrace?


2005-07-17  Paul Eggert  <address@hidden>

        * data/glr.c (yyparse): Don't assume that the initial calls
        to YYMALLOC succeed; in that case, yyparse incorrectly returned 0.
        Print a stack-overflow message and fail instead.
        Initialize the line-number information before creating the stack,
        so that the stack-overflow message can report line zero safely.

--- glr.c.~1.99.~       2005-07-14 16:01:32.000000000 -0700
+++ glr.c       2005-07-17 00:24:43.000000000 -0700
@@ -1967,14 +1967,6 @@ yyrecoverSyntaxError (yyGLRStack* yystac
   YYDPRINTF ((stderr, "Starting parse\n"));
 
   yytoken = YYEMPTY;
-
-  if (setjmp (yystack.yyexception_buffer) != 0)
-    goto yyDone;
-
-  if (! yyinitGLRStack (&yystack, YYINITDEPTH))
-    goto yyDone;
-  yystack.yytokenp = &yytoken;
-
   yylval = yyval_default;
 ]b4_location_if([
 #if YYLTYPE_IS_TRIVIAL
@@ -1992,6 +1984,11 @@ m4_popdef([b4_at_dollar])dnl
 /* Line __line__ of glr.c.  */
 b4_syncline(address@hidden@], address@hidden@])])dnl
 [
+  if (setjmp (yystack.yyexception_buffer) != 0)
+    goto yyDone;
+  if (! yyinitGLRStack (&yystack, YYINITDEPTH))
+    yyStackOverflow (&yystack]b4_lpure_args[);
+  yystack.yytokenp = &yytoken;
   yyglrShift (&yystack, 0, 0, 0, yylval, &yylloc]b4_user_args[);
   yyposn = 0;