Segmentation fault when trying to parse bison-3.8.2 grammar

[mingodad]

Doing experiments with byacc and trying to parse bison-3.8.2 grammar I found that byacc segfaults:

valgrind byacc-snapshots/yacc bison.y 
==754== Memcheck, a memory error detector
==754== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==754== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==754== Command:byacc-snapshots/yacc bison.y
==754== 
==754== Conditional jump or move depends on uninitialised value(s)
==754==    at 0x11AABF: copy_code (reader.c:707)
==754==    by 0x11DA24: read_declarations (reader.c:1837)
==754==    by 0x11E470: reader (reader.c:3931)
==754==    by 0x1102FB: main (main.c:878)
==754== 
==754== Use of uninitialised value of size 8
==754==    at 0x11AA13: copy_code (reader.c:709)
==754==    by 0x11DA24: read_declarations (reader.c:1837)
==754==    by 0x11E470: reader (reader.c:3931)
==754==    by 0x1102FB: main (main.c:878)
==754== 
==754== Conditional jump or move depends on uninitialised value(s)
==754==    at 0x11AA21: copy_code (reader.c:712)
==754==    by 0x11DA24: read_declarations (reader.c:1837)
==754==    by 0x11E470: reader (reader.c:3931)
==754==    by 0x1102FB: main (main.c:878)
==754== 
==754== Invalid read of size 1
==754==    at 0x11AAB3: copy_code (reader.c:706)
==754==    by 0x11DA24: read_declarations (reader.c:1837)
==754==    by 0x11E470: reader (reader.c:3931)
==754==    by 0x1102FB: main (main.c:878)
==754==  Address 0x5238f45 is 0 bytes after a block of size 101 alloc'd
==754==    at 0x4C32F6D: malloc (vg_replace_malloc.c:380)
==754==    by 0x11A3FD: get_line (reader.c:294)
==754==    by 0x11A944: next_inline (reader.c:383)
==754==    by 0x11A97C: nextc (reader.c:426)
==754==    by 0x11D4BC: read_declarations (reader.c:1821)
==754==    by 0x11E470: reader (reader.c:3931)
==754==    by 0x1102FB: main (main.c:878)
==754== 
==754== 
==754== Process terminating with default action of signal 11 (SIGSEGV)
==754==  Access not within mapped region at address 0x5634000
==754==    at 0x11AAB3: copy_code (reader.c:706)
==754==    by 0x11DA24: read_declarations (reader.c:1837)
==754==    by 0x11E470: reader (reader.c:3931)
==754==    by 0x1102FB: main (main.c:878)
==754==  If you believe this happened as a result of a stack
==754==  overflow in your program's main thread (unlikely but
==754==  possible), you can try to increase the size of the
==754==  main thread stack using the --main-stacksize= flag.
==754==  The main thread stack size used in this run was 8388608.
==754== 
==754== HEAP SUMMARY:
==754==     in use at exit: 10,947 bytes in 15 blocks
==754==   total heap usage: 18 allocs, 3 frees, 19,201 bytes allocated
==754== 
==754== LEAK SUMMARY:
==754==    definitely lost: 0 bytes in 0 blocks
==754==    indirectly lost: 0 bytes in 0 blocks
==754==      possibly lost: 0 bytes in 0 blocks
==754==    still reachable: 10,947 bytes in 15 blocks
==754==         suppressed: 0 bytes in 0 blocks
==754== Rerun with --leak-check=full to see details of leaked memory
==754== 
==754== Use --track-origins=yes to see where uninitialised values come from
==754== For lists of detected and suppressed errors, rerun with: -s
==754== ERROR SUMMARY: 4174078 errors from 4 contexts (suppressed: 0 from 0)
valgrind: line 2:   754 Segmentation fault      (core dumped) valgrind $*

[mingodad]

The problem seem that byacc expects the %code requires { to have the curly brace on the same line and blindly go forward looking for it without check end of line and the bison grammar has it written with new line %code requires\n{.

[mingodad]

This patch fixes the segmentation fault problem:

diff --git a/reader.c b/reader.c
index 5e8ca67..1e5015e 100644
--- a/reader.c
+++ b/reader.c
@@ -706,6 +706,15 @@ copy_code(void)
 	c = *++cptr;
 	if (c == EOF)
 	    unexpected_EOF();
+        if (c == '\0') {
+	    get_line();
+	    if (line == NULL)
+	    {
+		unexpected_EOF();
+		/*NOTREACHED */
+	    }
+	    c = *cptr;
+        }
 	if (isspace(UCH(c)))
 	    continue;
 

[ThomasDickey]

with that fix, it does not dump core, but will not handle the %define directives further in the file.

[mingodad]

This mean that somehow the patch will be applied ?

[ThomasDickey]

yes - I applied that, and it'll be in the next upload (perhaps in a few weeks - other programs are keeping me busy)