Re: bison segv under Cygwin 64 at fatal-signal.c:318

[Brian Inglis]

On 2021-09-16 08:30, Brian Inglis wrote:
> On 2021-09-16 04:44, Bruno Haible wrote:
> > > He also run gnulib's test suite, with results attached below
> > > (taken from https://lists.gnu.org/r/bug-bison/2021-09/msg00031.html).
>
> > Well, when I build the same tarball on Cygwin 2.9.0 64-bit, I get
> > much better results (10 failures, not 43 failures).
>
> Hi Bruno,
>
> Please note that latest bison built and passed all checks on latest 
> Cygwin 32.
> The issue is only with Cygwin 64.
> I consistently reproduced the SEGV @ 0x0000000100000000 with trashed 
> stack, in a gdb script.
> I reproduced the same results in both environments with bison 3.8/3.8.1 
> and gcc 10.2.0/11.2.0, to eliminate other possible concerns, over a few 
> days, before asking for help on bug-bison!
>
> How did you build that package?
>
> I built using latest Cygwin 3.2.0 with gcc 10.2.0 and ~150 Cygwin
> ...-devel packages available, using cygport --debug for logging, but 
> otherwise default package build with autoreconf, configure, make, check, 
> same as Cygwin 32 bison.
>
> I am currently rebuilding using just straight
>
>      $ configure --disable-silent-rules && make && make check
>
> into a parallel dummy-build dir (with logs), to hopefully get more 
> diagnostically useful check logs.
>
> I will also redo cygport with --disable-silent-rules after those builds 
> and checks complete (in a few hours).

Cygwin bison make check segv reproduces under Github actions CI:

        https://github.com/cygwin/scallywag/actions

        https://github.com/cygwin/scallywag/actions/runs/1242596862

click on x86_64 arch to see log and expand step 6 build;

click on gear * to see menu for Download log archive [all arches];

click on Summary top left then scroll to bottom to download Artifacts:

        * i686 builddir
        * i686 packages
        * metadata
        * x86_64 builddir
        * x86_64 packages.

Previous run for 3.7.6 is here:

        https://github.com/cygwin/scallywag/actions/runs/1201783190

I'm just remembering the previous time I saw something similar to this 
was when autoreconf/autoconf/ac....m4 was missing a symbol setting in 
sed stanza 's/UPPERCASE_PROPERTY/@UPPERCASE_PROPERTY@/g' where 
@UPPERCASE_PROPERTY@ was not set, that messed up preprocessing.

Were some m4 file(s) updated with new symbol settings in sed stanzas 
between 2.68 and 2.71, that may not be made by 2.69, perhaps something 
changed in tests for thread or pipe facilities that may not be done by 
2.69?

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]