Re: Testsuite summary for GNU Bison 3.8.2 : FAIL 2

[Dennis Clarke]

On 10/9/21 04:35, Akim Demaille wrote:
> Hi Dennis,
> 
> Thanks for this bug report.

The least I can do.

...
> 
>> Looks like ye old diff gets upset at an option there.
> 
> That's not a problem.  The test is actually checking whether it can use it or 
> not.  Hence the "checking for diff --strip-trailing-cr...".
> 

okay. good stuff.

> 
>> mfcalc: PASS: 1
>> mfcalc: PASS: 2
>> mfcalc: PASS: 3
>> mfcalc: FAIL: 4 (expected status: 0, effective: 139)
>> ./examples/test: line 50:  7737 Segmentation Fault      (core dumped)
>> "$abs_medir/$me" "$@"
>> mfcalc: PASS: 5
>> FAIL examples/c/mfcalc/mfcalc.test (exit status: 1)
> 
> However, this is bad.
> 
> Actually I guess that only the tests from the examples were run, and not the 
> main test suite.  So I guest if you run `make check-tests`, you'll get many 
> many failures.
> 
> If I'm not mistaken the fourth test of mfcalc is:
> 
> a = 256
> sqrt (a)
> 
> I doubt that the problem is in the parser itself, I venture it's sqrt that 
> does not work properly.  Let's try these inputs please:
> 
> echo 'a = 256' | ./examples/c/mfcalc/mfcalc
>

You will love this :

beta $
beta $ echo 'a = 256' | ./examples/c/mfcalc/mfcalc
ksh: 16411 Segmentation Fault(coredump)
beta $ dbx examples/c/mfcalc/mfcalc
../time_1634057100-pid_16411-uid_16411-gid_20002-fid_mfcalc.per-process-core
Reading mfcalc
core file header read successfully
Reading ld.so.1
Reading libm.so.2
Reading libc.so.1
program terminated by signal SEGV (no mapping at the fault address)
0xffffffff7eb3c18c: strcmp+0x00cc:      ldx      [%o1 + %o2], %o3
Current function is getsym
 1461       if (strcmp (p->name, name) == 0)
(dbx) list
 1461       if (strcmp (p->name, name) == 0)
 1462         return p;
 1463     return NULL;
 1464   }
 1465
 1466   #include <ctype.h>
 1467   #include <stddef.h>
 1468
 1469   int
 1470   yylex (void)
(dbx) print &p
&p = 0xffffffff7fffeb18
(dbx) print p
p = 0x100104410
(dbx) print *p
*p = {
    name  = 0x105bd0 "<bad address 0x0000000000105bd0>"
    type  = 260
    value = {
        var = 2.1225218246347e-314
        fun = 0x100103f00
    }
    next  = 0x1001043e0
}
(dbx) quit
beta $

Yep, that looks quite strange.

> { echo 'a = 256'; echo 'a+a'; } | ./examples/c/mfcalc/mfcalc
> 

I think we found where the problem is but not the cause :

beta $
beta $ { echo 'a = 256'; echo 'a+a'; } | ./examples/c/mfcalc/mfcalc
ksh: 18090 Segmentation Fault(coredump)
beta $ tn
1634076887
beta $ dbx ./examples/c/mfcalc/mfcalc
../time_1634076746-pid_18090-uid_16411-gid_20002-fid_mfcalc.core
Reading mfcalc
core file header read successfully
Reading ld.so.1
Reading libm.so.2
Reading libc.so.1
program terminated by signal SEGV (no mapping at the fault address)
0xffffffff7eb3c18c: strcmp+0x00cc:      ldx      [%o1 + %o2], %o3
Current function is getsym
 1461       if (strcmp (p->name, name) == 0)
(dbx) where
  [1] strcmp(0x105bd0, 0x100107f60, 0xfffffffeffffdc70, 0x0,
0x8080808080808080, 0x101010101010101), at 0xffffffff7eb3c18c
=>[2] getsym(name = 0x100107f60 "a"), line 1461 in "mfcalc.c"
  [3] yylex(), line 1514 in "mfcalc.c"
  [4] yyparse(), line 1076 in "mfcalc.c"
  [5] main(argc = 1, argv = 0xffffffff7ffff668), line 1537 in "mfcalc.c"
(dbx) list
 1461       if (strcmp (p->name, name) == 0)
 1462         return p;
 1463     return NULL;
 1464   }
 1465
 1466   #include <ctype.h>
 1467   #include <stddef.h>
 1468
 1469   int
 1470   yylex (void)
(dbx) quit
beta $

I guess we could keep going but I bet we just keep on tossing cores.

I will go back and re-read your email and see if I can also find where
this went wrong.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional