Re: SIGSEGV in test 316 on SPARCv9

[Akim Demaille]

Hi Martin,

Thanks a lot for your reports.  Sorry for not answering sooner,
but rest assured that your reports are on the radar.

> Le 30 nov. 2020 à 18:20, Martin Rehak <martin.rehak@oracle.com> a écrit :
> 
> stderr:                   
> 1.1                                                        
> 1.1: syntax error    
> ./testsuite[2584]: .: line 181: 19978: Memory fault(coredump)

Wow...

> It is reproducible just on SPARCv9, it passes on SPARCv7.

Same compiler?

> I have done some debugging on it. These are the arguments of bison and 
> g++ commands used:
> 
> $ bison --color=no -fno-caret -o input.cc input.y
> $ g++ -g -m64 -O3 -mno-app-regs 
> -ffile-prefix-map=/builds/mrehak/workspace/bison/components/bison=. \
>  -I/builds/mrehak/workspace/bison/components/bison/bison-3.7.3/tests 
> -D_REENTRANT -o input input.cc \
>  /builds/mrehak/workspace/bison/components/bison/build/sparcv9/lib/libbison.a

Great job, thanks!

What version of GCC is this?


> This is what gdb catches:
> 
> Reading symbols from ./input...
> (gdb) r
> Starting program: 
> /builds/mrehak/workspace/bison/components/bison/build/sparcv9/tests/testsuite.dir/316/input
>  
> [Thread debugging using libthread_db enabled]
> 1.1
> 1.1: syntax error
> [New Thread 1 (LWP 1)]

W00t???  I have no idea why it creates a thread here.  There's no such thing in 
the generated parser.

> Thread 2 received signal SIGSEGV, Segmentation fault.

What on Earth is going on here???

> And here is how yydestruct looks like in input.cc:
> 
> static void                                                                   
>                                          
> yydestruct (const char *yymsg, int yytype, YYSTYPE *yyvaluep, YYLTYPE 
> *yylocationp, yy::parser& yyparser)              
> {                                                                             
>                                          
>  YYUSE (yyvaluep);                                                            
>                                         
>  YYUSE (yylocationp);                                                         
>                                         
>  YYUSE (yyparser);                                                            
>                                         
>  if (!yymsg)                                                                  
>                                         
>    yymsg = "Deleting";                                                        
>                                         
>  YY_SYMBOL_PRINT (yymsg, yytype, yyvaluep, yylocationp);   // <- 1464
> 
>  YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN                                          
>                                         
> YYUSE (yytype);                                                               
>                                        
> YY_IGNORE_MAYBE_UNINITIALIZED_END                                             
>                                        
> }

So if I understood correctly you have a crash in line 1464 when traces are not 
enabled (i.e., but YYDEBUG is not set).  Which is weird, since:

# define YY_SYMBOL_PRINT(Title, Kind, Value, Location)                  \
  do {                                                                  \
    if (yydebug)                                                        \
      {                                                                 \
        YY_FPRINTF ((stderr, "%s ", Title));                            \
        yy_symbol_print (stderr, Kind, Value, Location, yyparser);        \
        YY_FPRINTF ((stderr, "\n"));                                    \
      }                                                                 \
  } while (0)

In other words, there is nothing to run here!

If you inline the macro by hand in line 1464, and compile again, what happens?

I'm very tempted to call this a compiler bug.