[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Brian Inglis
Subject: Re: bison segv under Cygwin 64 at fatal-signal.c:318
Date: Thu, 16 Sep 2021 12:20:58 -0600
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

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:



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:


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.]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]