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

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

[Akim Demaille]

[-- Attachment #1: Type: text/plain, Size: 3642 bytes --]

Dear gnulibers,

Brian Inglis reported that Bison crashes on Cygwin 64 (https://lists.gnu.org/r/bug-bison/2021-09/msg00024.html).  It works fine on Cygwin 32.

Brian provided a lot of debugging material in that thread:

> Trying to package bison 3.8/.1 for Cygwin - previous releases to 3.7.6 built and checked okay - bison 3.8.1 checked okay on 32 bit - all tests segv on 64 bit!
> 
> Reran build and check with bison 3.8 and 3.8.1 using gcc 10.2.0 and 11.2.0 under Cygwin 64 with no change as all tests segv @ 0x0000000100000000.
> 
> Build runs with autoreconf et al as per normal on 32 and 64 bit; adding debug output allowed me see test commands to narrow down cause.
> 
> Ran using gdb against tests/c/bistromathic/parse.y (see attached for gdb command, script, and full log) getting the output below.
> 
> It appears to be possible that `gl_lock_lock` expansion to `pthread_in_use() ? pthread_mutex_lock(...)` -> `glthread_in_use() ? ...` has avoided defining the latter in the build, or some underlying dynamic library function may not be loaded?
> 
> This could result from Cygwin being neither fish nor fowl: none of BSD, Sun, Windows, or Linux, although I notice some __CYGWIN__ conditionals.
> 
> ...
> 
> Thread 1 "bison" hit Breakpoint 10, block_fatal_signals () at /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c:318
> 318       if (mt) gl_lock_lock (fatal_signals_block_lock);
> Continuing.
> 
> Thread 1 "bison" received signal SIGSEGV, Segmentation fault.
> 0x0000000100000000 in ?? ()
> #0  0x0000000100000000 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)


> Wondering if somehow gnulib lib/glthread/tls.h:
> 
> ...
> 
> # if PTHREAD_IN_USE_DETECTION_HARD
> 
> /* The pthread_in_use() detection needs to be done at runtime.  */
> #  define pthread_in_use() \
>     glthread_in_use ()
> extern int glthread_in_use (void);
> 
> # endif
> 
> ...
> 
> #  if !PTHREAD_IN_USE_DETECTION_HARD
> #   define pthread_in_use() 1
> #  endif
> 
> ...
> 
> is being declared as int 1 somewhere, and being interpreted elsewhere as (glthread_in_use)() and used as address 0x0000000100000000?



> Thread 1 "bison" hit Breakpoint 10, block_fatal_signals () at /usr/src/debug/bison-3.8.1.27-dd6e/lib/fatal-signal.c:318
> 318	  if (mt) gl_lock_lock (fatal_signals_block_lock);
> +print &pthread_mutexattr_gettype
> $1 = (int (*)(const pthread_mutexattr_t *, int *)) 0x180167940 <pthread_mutexattr_gettype(pthread_mutexattr_t const*, int*)>
> +print &thrd_exit
> $2 = (void (*)(int)) 0x18018a3d0 <thrd_exit>
> +print &pthread_mutex_lock
> $3 = (int (*)(pthread_mutex_t *)) 0x1801670f0 <pthread_mutex_lock(pthread_mutex_t*)>
> +print &fatal_signals_block_lock
> $4 = (pthread_mutex_t *) 0x100466a50 <fatal_signals_block_lock>
> +print fatal_signals_block_lock
> $5 = (pthread_mutex_t) 0x13
> +enable 13
> +step
> 0x0000000100000000 in ?? ()
> +bt
> #0  0x0000000100000000 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)

He also run gnulib's test suite, with results attached below (taken from https://lists.gnu.org/r/bug-bison/2021-09/msg00031.html).

He reported that Bison 3.7.6 worked fine (gnulib 839ed059f49329993ed34699a6f6b6466f09cbe0, 2020-11-09).  It fails with Bison 3.8's gnulib (964ce0a92b9ba87afe7787dc0fd5d1e1abe7214c 2021-08-12), and likewise with 29d79d473f52b0ec58f50c95ef782c66fc0ead21 (2021-09-13).

But I don't know how to debug any further.  Is there anyone running cygwin that could help us?

Or should we try to bisect first?

Thanks in advance,

	Akim



[-- Attachment #2: dummy-logs.tar.xz --]
[-- Type: application/octet-stream, Size: 200192 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2 bytes --]

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

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

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

Bruno

[-- Attachment #2: test-suite.log --]
[-- Type: text/x-log, Size: 10472 bytes --]

=====================================
   dummy 0: gltests/test-suite.log
=====================================

# TOTAL: 1381
# PASS:  1315
# SKIP:  56
# XFAIL: 0
# FAIL:  10
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: test-c32rtomb-w32-1.sh
============================

Skipping test: not a native Windows system
SKIP test-c32rtomb-w32-1.sh (exit status: 77)

SKIP: test-c32rtomb-w32-2.sh
============================

Skipping test: not a native Windows system
SKIP test-c32rtomb-w32-2.sh (exit status: 77)

SKIP: test-c32rtomb-w32-3.sh
============================

Skipping test: not a native Windows system
SKIP test-c32rtomb-w32-3.sh (exit status: 77)

SKIP: test-c32rtomb-w32-4.sh
============================

Skipping test: not a native Windows system
SKIP test-c32rtomb-w32-4.sh (exit status: 77)

SKIP: test-c32rtomb-w32-5.sh
============================

Skipping test: not a native Windows system
SKIP test-c32rtomb-w32-5.sh (exit status: 77)

SKIP: test-c32rtomb-w32-6.sh
============================

Skipping test: not a native Windows system
SKIP test-c32rtomb-w32-6.sh (exit status: 77)

SKIP: test-c32rtomb-w32-7.sh
============================

Skipping test: not a native Windows system
SKIP test-c32rtomb-w32-7.sh (exit status: 77)

SKIP: test-c32snrtombs-4.sh
===========================

Skipping test: no transitional chinese locale is supported
SKIP test-c32snrtombs-4.sh (exit status: 77)

SKIP: test-c32srtombs-4.sh
==========================

Skipping test: no transitional chinese locale is supported
SKIP test-c32srtombs-4.sh (exit status: 77)

SKIP: test-c32stombs-4.sh
=========================

Skipping test: no transitional chinese locale is supported
SKIP test-c32stombs-4.sh (exit status: 77)

FAIL: test-fdutimensat
======================

../../gltests/test-lutimens.h:138: assertion 'get_stat_atime_ns (&st1) == get_stat_atime_ns (&st2)' failed
FAIL test-fdutimensat.exe (exit status: 134)

SKIP: test-fprintf-posix2.sh
============================

Skipping test: getrlimit and setrlimit don't work
SKIP test-fprintf-posix2.sh (exit status: 77)

SKIP: test-mbmemcasecmp3.sh
===========================

Skipping test: no turkish Unicode locale is supported
SKIP test-mbmemcasecmp3.sh (exit status: 77)

SKIP: test-mbmemcasecoll3.sh
============================

Skipping test: no turkish Unicode locale is supported
SKIP test-mbmemcasecoll3.sh (exit status: 77)

SKIP: test-mbrtoc32-4.sh
========================

Skipping test: no transitional chinese locale is supported
SKIP test-mbrtoc32-4.sh (exit status: 77)

SKIP: test-mbrtoc32-w32-1.sh
============================

Skipping test: not a native Windows system
SKIP test-mbrtoc32-w32-1.sh (exit status: 77)

SKIP: test-mbrtoc32-w32-2.sh
============================

Skipping test: not a native Windows system
SKIP test-mbrtoc32-w32-2.sh (exit status: 77)

SKIP: test-mbrtoc32-w32-3.sh
============================

Skipping test: not a native Windows system
SKIP test-mbrtoc32-w32-3.sh (exit status: 77)

SKIP: test-mbrtoc32-w32-4.sh
============================

Skipping test: not a native Windows system
SKIP test-mbrtoc32-w32-4.sh (exit status: 77)

SKIP: test-mbrtoc32-w32-5.sh
============================

Skipping test: not a native Windows system
SKIP test-mbrtoc32-w32-5.sh (exit status: 77)

SKIP: test-mbrtoc32-w32-6.sh
============================

Skipping test: not a native Windows system
SKIP test-mbrtoc32-w32-6.sh (exit status: 77)

SKIP: test-mbrtoc32-w32-7.sh
============================

Skipping test: not a native Windows system
SKIP test-mbrtoc32-w32-7.sh (exit status: 77)

SKIP: test-mbrtowc4.sh
======================

Skipping test: no transitional chinese locale is supported
SKIP test-mbrtowc4.sh (exit status: 77)

SKIP: test-mbrtowc-w32-1.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-1.sh (exit status: 77)

SKIP: test-mbrtowc-w32-2.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-2.sh (exit status: 77)

SKIP: test-mbrtowc-w32-3.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-3.sh (exit status: 77)

SKIP: test-mbrtowc-w32-4.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-4.sh (exit status: 77)

SKIP: test-mbrtowc-w32-5.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-5.sh (exit status: 77)

SKIP: test-mbrtowc-w32-6.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-6.sh (exit status: 77)

SKIP: test-mbrtowc-w32-7.sh
===========================

Skipping test: not a native Windows system
SKIP test-mbrtowc-w32-7.sh (exit status: 77)

SKIP: test-mbscasecmp.sh
========================

Skipping test: no turkish Unicode locale is supported
SKIP test-mbscasecmp.sh (exit status: 77)

SKIP: test-mbscasestr3.sh
=========================

Skipping test: no chinese GB18030 locale is supported
SKIP test-mbscasestr3.sh (exit status: 77)

SKIP: test-mbscasestr4.sh
=========================

Skipping test: no turkish Unicode locale is supported
SKIP test-mbscasestr4.sh (exit status: 77)

SKIP: test-mbschr.sh
====================

Skipping test: no chinese GB18030 locale is supported
SKIP test-mbschr.sh (exit status: 77)

SKIP: test-mbsncasecmp.sh
=========================

Skipping test: no turkish Unicode locale is supported
SKIP test-mbsncasecmp.sh (exit status: 77)

SKIP: test-mbsnrtoc32s-4.sh
===========================

Skipping test: no transitional chinese locale is supported
SKIP test-mbsnrtoc32s-4.sh (exit status: 77)

SKIP: test-mbsnrtowcs4.sh
=========================

Skipping test: no transitional chinese locale is supported
SKIP test-mbsnrtowcs4.sh (exit status: 77)

SKIP: test-mbspcasecmp.sh
=========================

Skipping test: no turkish Unicode locale is supported
SKIP test-mbspcasecmp.sh (exit status: 77)

SKIP: test-mbsrchr.sh
=====================

Skipping test: no chinese GB18030 locale is supported
SKIP test-mbsrchr.sh (exit status: 77)

SKIP: test-mbsrtoc32s-4.sh
==========================

Skipping test: no transitional chinese locale is supported
SKIP test-mbsrtoc32s-4.sh (exit status: 77)

SKIP: test-mbsrtowcs4.sh
========================

Skipping test: no transitional chinese locale is supported
SKIP test-mbsrtowcs4.sh (exit status: 77)

SKIP: test-mbsstr3.sh
=====================

Skipping test: no chinese GB18030 locale is supported
SKIP test-mbsstr3.sh (exit status: 77)

SKIP: test-mbstoc32s-4.sh
=========================

Skipping test: no transitional chinese locale is supported
SKIP test-mbstoc32s-4.sh (exit status: 77)

FAIL: test-passfd
=================

recvfd: Permission denied
FAIL test-passfd.exe (exit status: 16)

FAIL: test-pipe-filter-gi2.sh
=============================

../../gltests/test-pipe-filter-gi2-main.c:114: assertion 'rc == -1 && errno == EPIPE' failed
FAIL test-pipe-filter-gi2.sh (exit status: 1)

FAIL: test-poll
===============

Unconnected socket test... passed
Connected sockets test... passed
General socket test with fork... passed
Pipe test... failed (expecting POLLHUP after shutdown)
FAIL test-poll.exe (exit status: 1)

SKIP: test-printf-posix2.sh
===========================

Skipping test: getrlimit and setrlimit don't work
SKIP test-printf-posix2.sh (exit status: 77)

FAIL: test-ptsname
==================

../../gltests/test-ptsname.c:76: assertion 'result == NULL' failed
FAIL test-ptsname.exe (exit status: 134)

FAIL: test-ptsname_r
====================

../../gltests/test-ptsname_r.c:126: assertion 'result != 0' failed
FAIL test-ptsname_r.exe (exit status: 134)

FAIL: test-renameatu
====================

../../gltests/test-renameatu.c:195: assertion '(renameatu (dfd, BASE "sub2/file", dfd, BASE "sub2/file", RENAME_NOREPLACE) == -1) && errno == EEXIST' failed
FAIL test-renameatu.exe (exit status: 134)

SKIP: test-sethostname2
=======================

Skipping test: insufficient permissions.
SKIP test-sethostname2.exe (exit status: 77)

FAIL: test-tls
==============

Starting test_tls ... OK
Starting test_tls_dtorcheck1 ... OK
Starting test_tls_dtorcheck2 ... OK
Starting test_tls_racecheck ...FAIL test-tls.exe (exit status: 142)

SKIP: test-unicodeio3.sh
========================

Skipping test: no transitional chinese locale is supported
SKIP test-unicodeio3.sh (exit status: 77)

FAIL: test-utimens
==================

../../gltests/test-lutimens.h:137: assertion 'st1.st_atime == st2.st_atime' failed
FAIL test-utimens.exe (exit status: 134)

FAIL: test-utimensat
====================

../../gltests/test-lutimens.h:138: assertion 'get_stat_atime_ns (&st1) == get_stat_atime_ns (&st2)' failed
FAIL test-utimensat.exe (exit status: 134)

SKIP: test-vasnprintf-posix3
============================

Skipping test: not a glibc >= 2.3 system
SKIP test-vasnprintf-posix3.exe (exit status: 77)

SKIP: test-vc-list-files-cvs.sh
===============================

test-vc-list-files-cvs.sh: skipped test: cvs not found in PATH
SKIP test-vc-list-files-cvs.sh (exit status: 77)

SKIP: test-wcrtomb-w32-1.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-1.sh (exit status: 77)

SKIP: test-wcrtomb-w32-2.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-2.sh (exit status: 77)

SKIP: test-wcrtomb-w32-3.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-3.sh (exit status: 77)

SKIP: test-wcrtomb-w32-4.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-4.sh (exit status: 77)

SKIP: test-wcrtomb-w32-5.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-5.sh (exit status: 77)

SKIP: test-wcrtomb-w32-6.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-6.sh (exit status: 77)

SKIP: test-wcrtomb-w32-7.sh
===========================

Skipping test: not a native Windows system
SKIP test-wcrtomb-w32-7.sh (exit status: 77)

SKIP: test-wcsnrtombs4.sh
=========================

Skipping test: no transitional chinese locale is supported
SKIP test-wcsnrtombs4.sh (exit status: 77)

SKIP: test-wcsrtombs4.sh
========================

Skipping test: no transitional chinese locale is supported
SKIP test-wcsrtombs4.sh (exit status: 77)

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

[Brian Inglis]

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

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

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

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 9805 bytes --]

Brian Inglis wrote:
> 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.

Comparing the test failures that you got with those that I got, these
are those that are only in your env:
===============================================================================

FAIL: test-areadlinkat
======================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-areadlink.h:39: assertion 'errno == ENOENT || errno == EINVAL' failed
Aborted (core dumped)
FAIL test-areadlinkat.exe (exit status: 134)

FAIL: test-areadlinkat-with-size
================================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-areadlink.h:39: assertion 'errno == ENOENT || errno == EINVAL' failed
Aborted (core dumped)
FAIL test-areadlinkat-with-size.exe (exit status: 134)

FAIL: test-asyncsafe-spin2
==========================

Starting test_asyncsafe_spin ...Segmentation fault (core dumped)
FAIL test-asyncsafe-spin2.exe (exit status: 139)

FAIL: test-c-dtoastr.sh
=======================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/build-aux/test-driver: 107: $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-c-dtoastr.sh: Permission denied
FAIL test-c-dtoastr.sh (exit status: 126)

FAIL: test-c-ldtoastr.sh
========================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/build-aux/test-driver: 107: $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-c-ldtoastr.sh: Permission denied
FAIL test-c-ldtoastr.sh (exit status: 126)

FAIL: test-c32isgraph.sh
========================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-c32isgraph.c:125: assertion 'is != 0' failed
Aborted (core dumped)
FAIL test-c32isgraph.sh (exit status: 1)

FAIL: test-cond
===============

Starting test_cond ...Segmentation fault (core dumped)
FAIL test-cond.exe (exit status: 139)

FAIL: test-execute.sh
=====================

Segmentation fault (core dumped)
test-execute.sh: test case 0 failed
Segmentation fault (core dumped)
test-execute.sh: test case 1 failed
Segmentation fault (core dumped)
test-execute.sh: test case 2 failed
Segmentation fault (core dumped)
test-execute.sh: test case 3 failed
Segmentation fault (core dumped)
test-execute.sh: test case 4 failed
Segmentation fault (core dumped)
test-execute.sh: test case 5 failed
Segmentation fault (core dumped)
test-execute.sh: test case 6 failed
Segmentation fault (core dumped)
test-execute.sh: test case 7 failed
Segmentation fault (core dumped)
test-execute.sh: test case 8 failed
Segmentation fault (core dumped)
test-execute.sh: test case 9 failed
Segmentation fault (core dumped)
test-execute.sh: test case 10 failed
Segmentation fault (core dumped)
test-execute.sh: test case 11 failed
Segmentation fault (core dumped)
test-execute.sh: test case 12 failed
Segmentation fault (core dumped)
test-execute.sh: test case 13 failed
Segmentation fault (core dumped)
test-execute.sh: test case 14 failed
Segmentation fault (core dumped)
test-execute.sh: test case 15 failed
Segmentation fault (core dumped)
test-execute.sh: test case 16 failed
Segmentation fault (core dumped)
test-execute.sh: test case 17 failed
Segmentation fault (core dumped)
test-execute.sh: test case 18 failed
Segmentation fault (core dumped)
test-execute.sh: test case 19 failed
Segmentation fault (core dumped)
test-execute.sh: test case 20 failed
Segmentation fault (core dumped)
test-execute.sh: test case 21 failed
FAIL test-execute.sh (exit status: 1)

FAIL: test-execute-script
=========================

Segmentation fault (core dumped)
FAIL test-execute-script.exe (exit status: 139)

FAIL: test-file-has-acl.sh
==========================

setfacl: Invalid argument
file_has_acl("tmpfile0") returned yes, expected no
FAIL test-file-has-acl.sh (exit status: 1)

FAIL: test-file-has-acl-1.sh
============================

setfacl: Invalid argument
file_has_acl("tmpfile0") returned yes, expected no
FAIL test-file-has-acl-1.sh (exit status: 1)

FAIL: test-file-has-acl-2.sh
============================

setfacl: Invalid argument
file_has_acl("tmpfile0") returned yes, expected no
FAIL test-file-has-acl-2.sh (exit status: 1)

SKIP: test-fprintf-posix2.sh
============================

Skipping test: getrlimit and setrlimit don't work
SKIP test-fprintf-posix2.sh (exit status: 77)

FAIL: test-fstrcmp
==================

Segmentation fault (core dumped)
FAIL test-fstrcmp.exe (exit status: 139)

FAIL: test-getumask
===================

Segmentation fault (core dumped)
FAIL test-getumask.exe (exit status: 139)

FAIL: test-ilogbl
=================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-ilogb.h:68: assertion 'ILOGB (NAN) == FP_ILOGBNAN' failed
Aborted (core dumped)
FAIL test-ilogbl.exe (exit status: 134)

FAIL: test-immutable.sh
=======================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/build-aux/test-driver: 107: $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-immutable.sh: Permission denied
FAIL test-immutable.sh (exit status: 126)

FAIL: test-localename
=====================

Segmentation fault (core dumped)
FAIL test-localename.exe (exit status: 139)

FAIL: test-rwlock1
==================

Segmentation fault (core dumped)
FAIL test-rwlock1.exe (exit status: 139)

FAIL: test-once1
================

Segmentation fault (core dumped)
FAIL test-once1.exe (exit status: 139)

FAIL: test-once2
================

Segmentation fault (core dumped)
FAIL test-once2.exe (exit status: 139)

FAIL: test-mtx
==============

Starting test_mtx_plain ... OK
Starting test_mtx_recursive ... OK
Starting test_once ...Segmentation fault (core dumped)
FAIL test-mtx.exe (exit status: 139)

FAIL: test-passfd
=================

recvfd: Permission denied
FAIL test-passfd.exe (exit status: 16)

FAIL: test-pipe-filter-gi1.sh
=============================

Segmentation fault (core dumped)
FAIL test-pipe-filter-gi1.sh (exit status: 1)

FAIL: test-pipe-filter-gi2.sh
=============================

Segmentation fault (core dumped)
FAIL test-pipe-filter-gi2.sh (exit status: 1)

FAIL: test-pipe-filter-ii1.sh
=============================

Segmentation fault (core dumped)
FAIL test-pipe-filter-ii1.sh (exit status: 1)

FAIL: test-pipe-filter-ii2.sh
=============================

Segmentation fault (core dumped)
FAIL test-pipe-filter-ii2.sh (exit status: 1)

FAIL: test-raise
================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-raise.c:42: assertion 'raise (-1) != 0' failed
Aborted (core dumped)
FAIL test-raise.exe (exit status: 134)

FAIL: test-readlinkat
=====================

$HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-readlink.h:41: assertion 'errno == ENOENT || errno == EINVAL' failed
Aborted (core dumped)
FAIL test-readlinkat.exe (exit status: 134)

FAIL: test-regex-quote
======================

Segmentation fault (core dumped)
FAIL test-regex-quote.exe (exit status: 139)

FAIL: test-regex
================

Segmentation fault (core dumped)
FAIL test-regex.exe (exit status: 139)

FAIL: test-setlocale_null
=========================

Segmentation fault (core dumped)
FAIL test-setlocale_null.exe (exit status: 139)

FAIL: test-setlocale1.sh
========================

Segmentation fault (core dumped)
FAIL test-setlocale1.sh (exit status: 1)

FAIL: test-simple-atomic
========================

Segmentation fault (core dumped)
FAIL test-simple-atomic.exe (exit status: 139)

FAIL: test-spawn-pipe.sh
========================

Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 0 failed
Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 1 failed
Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 2 failed
Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 3 failed
Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 4 failed
Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 5 failed
Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 6 failed
Segmentation fault (core dumped)
test-spawn-pipe.sh: iteration 7 failed
FAIL test-spawn-pipe.sh (exit status: 1)

FAIL: test-spawn-pipe-script
============================

Segmentation fault (core dumped)
FAIL test-spawn-pipe-script.exe (exit status: 139)

FAIL: test-ssfmalloc
====================

Segmentation fault (core dumped)
FAIL test-ssfmalloc.exe (exit status: 139)

FAIL: test-supersede
====================

Segmentation fault (core dumped)
FAIL test-supersede.exe (exit status: 139)

FAIL: test-term-style-control-hello
===================================

Segmentation fault (core dumped)
FAIL test-term-style-control-hello.exe (exit status: 139)

FAIL: test-thread_self
======================

Segmentation fault (core dumped)
FAIL test-thread_self.exe (exit status: 139)

FAIL: test-thread_create
========================

Segmentation fault (core dumped)
FAIL test-thread_create.exe (exit status: 139)

FAIL: test-tls
==============

Starting test_tls ...Segmentation fault (core dumped)
FAIL test-tls.exe (exit status: 139)

===============================================================================

Among these, the most intriguing one is
  FAIL: test-thread_self
because that test is so small.

Find attached a smaller testdir, created through
  ./gnulib-tool --create-testdir --dir=../testdir-thread --single-configure thread

Does it work (with '../configure -C && make && make check', in a subdirectory)?

Can you also try to build it through

  gl_cv_have_weak=no ../configure -C && make && make check

in a different subdirectory?

Please send the config.log, config.cache, config.status, and
gltests/test-suite.log for each run.

Bruno

[-- Attachment #2: testdir-thread.tar.xz --]
[-- Type: application/x-xz-compressed-tar, Size: 270276 bytes --]

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

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 10902 bytes --]

On 2021-09-16 12:08, Bruno Haible wrote:
> Brian Inglis wrote:
>> 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.
> 
> Comparing the test failures that you got with those that I got, these
> are those that are only in your env:
> ===============================================================================
> 
> FAIL: test-areadlinkat
> ======================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-areadlink.h:39: assertion 'errno == ENOENT || errno == EINVAL' failed
> Aborted (core dumped)
> FAIL test-areadlinkat.exe (exit status: 134)
> 
> FAIL: test-areadlinkat-with-size
> ================================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-areadlink.h:39: assertion 'errno == ENOENT || errno == EINVAL' failed
> Aborted (core dumped)
> FAIL test-areadlinkat-with-size.exe (exit status: 134)
> 
> FAIL: test-asyncsafe-spin2
> ==========================
> 
> Starting test_asyncsafe_spin ...Segmentation fault (core dumped)
> FAIL test-asyncsafe-spin2.exe (exit status: 139)
> 
> FAIL: test-c-dtoastr.sh
> =======================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/build-aux/test-driver: 107: $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-c-dtoastr.sh: Permission denied
> FAIL test-c-dtoastr.sh (exit status: 126)
> 
> FAIL: test-c-ldtoastr.sh
> ========================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/build-aux/test-driver: 107: $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-c-ldtoastr.sh: Permission denied
> FAIL test-c-ldtoastr.sh (exit status: 126)
> 
> FAIL: test-c32isgraph.sh
> ========================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-c32isgraph.c:125: assertion 'is != 0' failed
> Aborted (core dumped)
> FAIL test-c32isgraph.sh (exit status: 1)
> 
> FAIL: test-cond
> ===============
> 
> Starting test_cond ...Segmentation fault (core dumped)
> FAIL test-cond.exe (exit status: 139)
> 
> FAIL: test-execute.sh
> =====================
> 
> Segmentation fault (core dumped)
> test-execute.sh: test case 0 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 1 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 2 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 3 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 4 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 5 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 6 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 7 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 8 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 9 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 10 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 11 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 12 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 13 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 14 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 15 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 16 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 17 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 18 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 19 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 20 failed
> Segmentation fault (core dumped)
> test-execute.sh: test case 21 failed
> FAIL test-execute.sh (exit status: 1)
> 
> FAIL: test-execute-script
> =========================
> 
> Segmentation fault (core dumped)
> FAIL test-execute-script.exe (exit status: 139)
> 
> FAIL: test-file-has-acl.sh
> ==========================
> 
> setfacl: Invalid argument
> file_has_acl("tmpfile0") returned yes, expected no
> FAIL test-file-has-acl.sh (exit status: 1)
> 
> FAIL: test-file-has-acl-1.sh
> ============================
> 
> setfacl: Invalid argument
> file_has_acl("tmpfile0") returned yes, expected no
> FAIL test-file-has-acl-1.sh (exit status: 1)
> 
> FAIL: test-file-has-acl-2.sh
> ============================
> 
> setfacl: Invalid argument
> file_has_acl("tmpfile0") returned yes, expected no
> FAIL test-file-has-acl-2.sh (exit status: 1)
> 
> SKIP: test-fprintf-posix2.sh
> ============================
> 
> Skipping test: getrlimit and setrlimit don't work
> SKIP test-fprintf-posix2.sh (exit status: 77)
> 
> FAIL: test-fstrcmp
> ==================
> 
> Segmentation fault (core dumped)
> FAIL test-fstrcmp.exe (exit status: 139)
> 
> FAIL: test-getumask
> ===================
> 
> Segmentation fault (core dumped)
> FAIL test-getumask.exe (exit status: 139)
> 
> FAIL: test-ilogbl
> =================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-ilogb.h:68: assertion 'ILOGB (NAN) == FP_ILOGBNAN' failed
> Aborted (core dumped)
> FAIL test-ilogbl.exe (exit status: 134)
> 
> FAIL: test-immutable.sh
> =======================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/build-aux/test-driver: 107: $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-immutable.sh: Permission denied
> FAIL test-immutable.sh (exit status: 126)
> 
> FAIL: test-localename
> =====================
> 
> Segmentation fault (core dumped)
> FAIL test-localename.exe (exit status: 139)
> 
> FAIL: test-rwlock1
> ==================
> 
> Segmentation fault (core dumped)
> FAIL test-rwlock1.exe (exit status: 139)
> 
> FAIL: test-once1
> ================
> 
> Segmentation fault (core dumped)
> FAIL test-once1.exe (exit status: 139)
> 
> FAIL: test-once2
> ================
> 
> Segmentation fault (core dumped)
> FAIL test-once2.exe (exit status: 139)
> 
> FAIL: test-mtx
> ==============
> 
> Starting test_mtx_plain ... OK
> Starting test_mtx_recursive ... OK
> Starting test_once ...Segmentation fault (core dumped)
> FAIL test-mtx.exe (exit status: 139)
> 
> FAIL: test-passfd
> =================
> 
> recvfd: Permission denied
> FAIL test-passfd.exe (exit status: 16)
> 
> FAIL: test-pipe-filter-gi1.sh
> =============================
> 
> Segmentation fault (core dumped)
> FAIL test-pipe-filter-gi1.sh (exit status: 1)
> 
> FAIL: test-pipe-filter-gi2.sh
> =============================
> 
> Segmentation fault (core dumped)
> FAIL test-pipe-filter-gi2.sh (exit status: 1)
> 
> FAIL: test-pipe-filter-ii1.sh
> =============================
> 
> Segmentation fault (core dumped)
> FAIL test-pipe-filter-ii1.sh (exit status: 1)
> 
> FAIL: test-pipe-filter-ii2.sh
> =============================
> 
> Segmentation fault (core dumped)
> FAIL test-pipe-filter-ii2.sh (exit status: 1)
> 
> FAIL: test-raise
> ================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-raise.c:42: assertion 'raise (-1) != 0' failed
> Aborted (core dumped)
> FAIL test-raise.exe (exit status: 134)
> 
> FAIL: test-readlinkat
> =====================
> 
> $HOME/src/cygwin/bison/dummy-0-0.x86_64/src/dummy-0/gltests/test-readlink.h:41: assertion 'errno == ENOENT || errno == EINVAL' failed
> Aborted (core dumped)
> FAIL test-readlinkat.exe (exit status: 134)
> 
> FAIL: test-regex-quote
> ======================
> 
> Segmentation fault (core dumped)
> FAIL test-regex-quote.exe (exit status: 139)
> 
> FAIL: test-regex
> ================
> 
> Segmentation fault (core dumped)
> FAIL test-regex.exe (exit status: 139)
> 
> FAIL: test-setlocale_null
> =========================
> 
> Segmentation fault (core dumped)
> FAIL test-setlocale_null.exe (exit status: 139)
> 
> FAIL: test-setlocale1.sh
> ========================
> 
> Segmentation fault (core dumped)
> FAIL test-setlocale1.sh (exit status: 1)
> 
> FAIL: test-simple-atomic
> ========================
> 
> Segmentation fault (core dumped)
> FAIL test-simple-atomic.exe (exit status: 139)
> 
> FAIL: test-spawn-pipe.sh
> ========================
> 
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 0 failed
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 1 failed
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 2 failed
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 3 failed
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 4 failed
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 5 failed
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 6 failed
> Segmentation fault (core dumped)
> test-spawn-pipe.sh: iteration 7 failed
> FAIL test-spawn-pipe.sh (exit status: 1)
> 
> FAIL: test-spawn-pipe-script
> ============================
> 
> Segmentation fault (core dumped)
> FAIL test-spawn-pipe-script.exe (exit status: 139)
> 
> FAIL: test-ssfmalloc
> ====================
> 
> Segmentation fault (core dumped)
> FAIL test-ssfmalloc.exe (exit status: 139)
> 
> FAIL: test-supersede
> ====================
> 
> Segmentation fault (core dumped)
> FAIL test-supersede.exe (exit status: 139)
> 
> FAIL: test-term-style-control-hello
> ===================================
> 
> Segmentation fault (core dumped)
> FAIL test-term-style-control-hello.exe (exit status: 139)
> 
> FAIL: test-thread_self
> ======================
> 
> Segmentation fault (core dumped)
> FAIL test-thread_self.exe (exit status: 139)
> 
> FAIL: test-thread_create
> ========================
> 
> Segmentation fault (core dumped)
> FAIL test-thread_create.exe (exit status: 139)
> 
> FAIL: test-tls
> ==============
> 
> Starting test_tls ...Segmentation fault (core dumped)
> FAIL test-tls.exe (exit status: 139)
> 
> ===============================================================================
> 
> Among these, the most intriguing one is
>    FAIL: test-thread_self
> because that test is so small.
> 
> Find attached a smaller testdir, created through
>    ./gnulib-tool --create-testdir --dir=../testdir-thread --single-configure thread
> 
> Does it work (with '../configure -C && make && make check', in a subdirectory)?
> 
> Can you also try to build it through
> 
>    gl_cv_have_weak=no ../configure -C && make && make check
> 
> in a different subdirectory?
> 
> Please send the config.log, config.cache, config.status, and
> gltests/test-suite.log for each run.

Done and attached, also including top level stdout/stderr logs for each 
command in each list, all lightly sanitized.

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


[-- Attachment #2: gnulib-testdir-no-weak.tar.xz --]
[-- Type: application/octet-stream, Size: 39844 bytes --]

[-- Attachment #3: gnulib-testsubdir.tar.xz --]
[-- Type: application/octet-stream, Size: 39936 bytes --]

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

[Bruno Haible]

Brian Inglis wrote:
> > Can you also try to build it through
> > 
> >    gl_cv_have_weak=no ../configure -C && make && make check
> > 
> > in a different subdirectory?
> > 
> > Please send the config.log, config.cache, config.status, and
> > gltests/test-suite.log for each run.
> 
> Done and attached

Thanks! Indeed, gl_cv_have_weak=no appears to make the essential difference.
Therefore, I'm applying this fix.


2021-09-17  Bruno Haible  <bruno@clisp.org>

	threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
	Reported by Brian Inglis via Akim Demaille in
	<https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00063.html>.
	* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
	Cygwin.

diff -w --git a/m4/threadlib.m4 b/m4/threadlib.m4
index 37b797c18..6b43bbdfa 100644
--- a/m4/threadlib.m4
+++ b/m4/threadlib.m4
@@ -1,4 +1,4 @@
-# threadlib.m4 serial 31
+# threadlib.m4 serial 32
 dnl Copyright (C) 2005-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -84,7 +84,15 @@ AC_DEFUN([gl_WEAK_SYMBOLS],
   AC_REQUIRE([AC_CANONICAL_HOST])
   AC_CACHE_CHECK([whether imported symbols can be declared weak],
     [gl_cv_have_weak],
-    [gl_cv_have_weak=no
+    [case "$host_os" in
+       cygwin*)
+         dnl On Cygwin 3.2.0 with gcc 10.2, the test below would succeed, but
+         dnl programs that use pthread_in_use() with weak symbol references
+         dnl crash miserably at runtime.
+         gl_cv_have_weak="guessing no"
+         ;;
+       *)
+         gl_cv_have_weak=no
          dnl First, test whether the compiler accepts it syntactically.
          AC_LINK_IFELSE(
            [AC_LANG_PROGRAM(
@@ -116,6 +124,8 @@ int main ()
                 [gl_cv_have_weak="guessing no"])
              ])
          fi
+         ;;
+     esac
      dnl But when linking statically, weak symbols don't work.
      case " $LDFLAGS " in
        *" -static "*) gl_cv_have_weak=no ;;

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

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

On 2021-09-17 14:25, Bruno Haible wrote:
> Brian Inglis wrote:
>>> Can you also try to build it through
>>>
>>>     gl_cv_have_weak=no ../configure -C && make && make check
>>>
>>> in a different subdirectory?
>>>
>>> Please send the config.log, config.cache, config.status, and
>>> gltests/test-suite.log for each run.
>>
>> Done and attached
> 
> Thanks! Indeed, gl_cv_have_weak=no appears to make the essential difference.
> Therefore, I'm applying this fix.
> 
> 
> 2021-09-17  Bruno Haible  <bruno@clisp.org>
> 
> 	threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
> 	Reported by Brian Inglis via Akim Demaille in
> 	<https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00063.html>.
> 	* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
> 	Cygwin.
> 
> diff -w --git a/m4/threadlib.m4 b/m4/threadlib.m4
> index 37b797c18..6b43bbdfa 100644
> --- a/m4/threadlib.m4
> +++ b/m4/threadlib.m4
> @@ -1,4 +1,4 @@
> -# threadlib.m4 serial 31
> +# threadlib.m4 serial 32
>   dnl Copyright (C) 2005-2021 Free Software Foundation, Inc.
>   dnl This file is free software; the Free Software Foundation
>   dnl gives unlimited permission to copy and/or distribute it,
> @@ -84,7 +84,15 @@ AC_DEFUN([gl_WEAK_SYMBOLS],
>     AC_REQUIRE([AC_CANONICAL_HOST])
>     AC_CACHE_CHECK([whether imported symbols can be declared weak],
>       [gl_cv_have_weak],
> -    [gl_cv_have_weak=no
> +    [case "$host_os" in
> +       cygwin*)
> +         dnl On Cygwin 3.2.0 with gcc 10.2, the test below would succeed, but
> +         dnl programs that use pthread_in_use() with weak symbol references
> +         dnl crash miserably at runtime.
> +         gl_cv_have_weak="guessing no"
> +         ;;
> +       *)
> +         gl_cv_have_weak=no
>            dnl First, test whether the compiler accepts it syntactically.
>            AC_LINK_IFELSE(
>              [AC_LANG_PROGRAM(
> @@ -116,6 +124,8 @@ int main ()
>                   [gl_cv_have_weak="guessing no"])
>                ])
>            fi
> +         ;;
> +     esac
>        dnl But when linking statically, weak symbols don't work.
>        case " $LDFLAGS " in
>          *" -static "*) gl_cv_have_weak=no ;;

Patch would not apply as included gnulib and bison threadlib.m4 appear 
to be from July and August.
Respun and applied patch successfully to glm4/threadlib.m4.
Still did not change gnulib or bison builds to configure weak=no or 
check successfully.
Were there additional conditions required to ensure that was used?

Had to configure with explicit gl_cv_have_weak=no arg to successfully 
configure and run tests.

Please see attached tars for logs and config.*.

Patch also made no difference to bison build, but adding to CYGCONF_ARGS 
explicit gl_cv_have_weak=no allowed all tests to run:

* D, Java, 129: Output file name: `~!..., 150: Tabulations and multibyte 
characters, 283-287: syncline escapes, 647: LAC: Exploratory stack, were 
skipped;

* all but two others 672-673: Doxygen Public-Private Documentation were 
successful.

Please see attached bison...check.log.gz.

So the diagnosis and cure were correct and worked, but the patch did not 
seem to make any difference?

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

[-- Attachment #2: bison-3.8.1-0-check.log.gz --]
[-- Type: application/x-gzip, Size: 13005 bytes --]

[-- Attachment #3: gnulib-testdir-build.tar.xz --]
[-- Type: application/octet-stream, Size: 36872 bytes --]

[-- Attachment #4: gnulib-testdir-weak-no.tar.xz --]
[-- Type: application/octet-stream, Size: 36520 bytes --]

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

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 4013 bytes --]

On 2021-09-18 07:22, Brian Inglis wrote:
> On 2021-09-17 14:25, Bruno Haible wrote:
>> Brian Inglis wrote:
>>>> Can you also try to build it through
>>>>
>>>>     gl_cv_have_weak=no ../configure -C && make && make check
>>>>
>>>> in a different subdirectory?
>>>>
>>>> Please send the config.log, config.cache, config.status, and
>>>> gltests/test-suite.log for each run.
>>>
>>> Done and attached
>>
>> Thanks! Indeed, gl_cv_have_weak=no appears to make the essential 
>> difference.
>> Therefore, I'm applying this fix.
>>
>>
>> 2021-09-17  Bruno Haible  <bruno@clisp.org>
>>
>>     threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
>>     Reported by Brian Inglis via Akim Demaille in
>>     <https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00063.html>. 
>>
>>     * m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
>>     Cygwin.
>>
>> diff -w --git a/m4/threadlib.m4 b/m4/threadlib.m4
>> index 37b797c18..6b43bbdfa 100644
>> --- a/m4/threadlib.m4
>> +++ b/m4/threadlib.m4
>> @@ -1,4 +1,4 @@
>> -# threadlib.m4 serial 31
>> +# threadlib.m4 serial 32
>>   dnl Copyright (C) 2005-2021 Free Software Foundation, Inc.
>>   dnl This file is free software; the Free Software Foundation
>>   dnl gives unlimited permission to copy and/or distribute it,
>> @@ -84,7 +84,15 @@ AC_DEFUN([gl_WEAK_SYMBOLS],
>>     AC_REQUIRE([AC_CANONICAL_HOST])
>>     AC_CACHE_CHECK([whether imported symbols can be declared weak],
>>       [gl_cv_have_weak],
>> -    [gl_cv_have_weak=no
>> +    [case "$host_os" in
>> +       cygwin*)
>> +         dnl On Cygwin 3.2.0 with gcc 10.2, the test below would 
>> succeed, but
>> +         dnl programs that use pthread_in_use() with weak symbol 
>> references
>> +         dnl crash miserably at runtime.
>> +         gl_cv_have_weak="guessing no"
>> +         ;;
>> +       *)
>> +         gl_cv_have_weak=no
>>            dnl First, test whether the compiler accepts it syntactically.
>>            AC_LINK_IFELSE(
>>              [AC_LANG_PROGRAM(
>> @@ -116,6 +124,8 @@ int main ()
>>                   [gl_cv_have_weak="guessing no"])
>>                ])
>>            fi
>> +         ;;
>> +     esac
>>        dnl But when linking statically, weak symbols don't work.
>>        case " $LDFLAGS " in
>>          *" -static "*) gl_cv_have_weak=no ;;
> 
> Patch would not apply as included gnulib and bison threadlib.m4 appear 
> to be from July and August.
> Respun and applied patch successfully to glm4/threadlib.m4.
> Still did not change gnulib or bison builds to configure weak=no or 
> check successfully.
> Were there additional conditions required to ensure that was used?
> 
> Had to configure with explicit gl_cv_have_weak=no arg to successfully 
> configure and run tests.
> 
> Please see attached tars for logs and config.*.
> 
> Patch also made no difference to bison build, but adding to CYGCONF_ARGS 
> explicit gl_cv_have_weak=no allowed all tests to run:
> 
> * D, Java, 129: Output file name: `~!..., 150: Tabulations and multibyte 
> characters, 283-287: syncline escapes, 647: LAC: Exploratory stack, were 
> skipped;
> 
> * all but two others 672-673: Doxygen Public-Private Documentation were 
> successful.
> 
> Please see attached bison...check.log.gz.
> 
> So the diagnosis and cure were correct and worked, but the patch did not 
> seem to make any difference?

[Dropping bug-bison]

Attaching the patches provided by Bruno (gnulib/...orig.patch), respun 
for gnulib config tests (gnulib/...patch), and respun for bison config 
tests (threadlib...patch).

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

[-- Attachment #2: gnulib-threadlib-m4-31-cygwin-weak-no.orig.patch --]
[-- Type: text/plain, Size: 1662 bytes --]

2021-09-17  Bruno Haible  <bruno@clisp.org>

	threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
	Reported by Brian Inglis via Akim Demaille in
	<https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00063.html>.
	* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
	Cygwin.

diff -w --git a/m4/threadlib.m4 b/m4/threadlib.m4
index 37b797c18..6b43bbdfa 100644
--- a/glm4/threadlib.m4	2021-08-02 23:51:08 -0600
+++ b/glm4/threadlib.m4	2021-09-17 14:52:21 -0600
@@ -1,4 +1,4 @@
-# threadlib.m4 serial 31
+# threadlib.m4 serial 32
 dnl Copyright (C) 2005-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -84,7 +84,15 @@ AC_DEFUN([gl_WEAK_SYMBOLS],
   AC_REQUIRE([AC_CANONICAL_HOST])
   AC_CACHE_CHECK([whether imported symbols can be declared weak],
     [gl_cv_have_weak],
-    [gl_cv_have_weak=no
+    [case "$host_os" in
+       cygwin*)
+         dnl On Cygwin 3.2.0 with gcc 10.2, the test below would succeed, but
+         dnl programs that use pthread_in_use() with weak symbol references
+         dnl crash miserably at runtime.
+         gl_cv_have_weak="guessing no"
+         ;;
+       *)
+         gl_cv_have_weak=no
       dnl First, test whether the compiler accepts it syntactically.
       AC_LINK_IFELSE(
         [AC_LANG_PROGRAM(
@@ -116,6 +124,8 @@ int main ()
             [gl_cv_have_weak="guessing no"])
          ])
      fi
+         ;;
+     esac
      dnl But when linking statically, weak symbols don't work.
      case " $LDFLAGS " in
        *" -static "*) gl_cv_have_weak=no ;;

[-- Attachment #3: gnulib-threadlib-m4-31-cygwin-weak-no.patch --]
[-- Type: text/plain, Size: 3455 bytes --]

2021-09-17  Bruno Haible  <bruno@clisp.org>

	threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
	Reported by Brian Inglis via Akim Demaille in
	<https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00063.html>.
	* m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
	Cygwin.

diff -w --git a/m4/threadlib.m4 b/m4/threadlib.m4
index 37b797c18..6b43bbdfa 100644
--- a/glm4/threadlib.m4	2021-07-17 10:19:19.000000000 -0600
+++ b/glm4/threadlib.m4	2021-09-17 21:06:03.205361000 -0600
@@ -1,4 +1,4 @@
-# threadlib.m4 serial 31
+# threadlib.m4 serial 32
 dnl Copyright (C) 2005-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -84,38 +84,48 @@ AC_DEFUN([gl_WEAK_SYMBOLS],
   AC_REQUIRE([AC_CANONICAL_HOST])
   AC_CACHE_CHECK([whether imported symbols can be declared weak],
     [gl_cv_have_weak],
-    [gl_cv_have_weak=no
-     dnl First, test whether the compiler accepts it syntactically.
-     AC_LINK_IFELSE(
-       [AC_LANG_PROGRAM(
-          [[extern void xyzzy ();
+    [case "$host_os" in
+       cygwin*)
+         dnl On Cygwin 3.2.0 with gcc 10.2, the test below would succeed, but
+         dnl programs that use pthread_in_use() with weak symbol references
+         dnl crash miserably at runtime.
+         gl_cv_have_weak="guessing no"
+         ;;
+       *)
+        gl_cv_have_weak=no
+        dnl First, test whether the compiler accepts it syntactically.
+        AC_LINK_IFELSE(
+          [AC_LANG_PROGRAM(
+             [[extern void xyzzy ();
 #pragma weak xyzzy]],
-          [[xyzzy();]])],
-       [gl_cv_have_weak=maybe])
-     if test $gl_cv_have_weak = maybe; then
-       dnl Second, test whether it actually works. On Cygwin 1.7.2, with
-       dnl gcc 4.3, symbols declared weak always evaluate to the address 0.
-       AC_RUN_IFELSE(
-         [AC_LANG_SOURCE([[
+             [[xyzzy();]])],
+          [gl_cv_have_weak=maybe])
+        if test $gl_cv_have_weak = maybe; then
+          dnl Second, test whether it actually works. On Cygwin 1.7.2, with
+          dnl gcc 4.3, symbols declared weak always evaluate to the address 0.
+          AC_RUN_IFELSE(
+            [AC_LANG_SOURCE([[
 #include <stdio.h>
 #pragma weak fputs
 int main ()
 {
   return (fputs == NULL);
 }]])],
-         [gl_cv_have_weak=yes],
-         [gl_cv_have_weak=no],
-         [dnl When cross-compiling, assume that only ELF platforms support
-          dnl weak symbols.
-          AC_EGREP_CPP([Extensible Linking Format],
-            [#ifdef __ELF__
-             Extensible Linking Format
-             #endif
-            ],
-            [gl_cv_have_weak="guessing yes"],
-            [gl_cv_have_weak="guessing no"])
-         ])
-     fi
+            [gl_cv_have_weak=yes],
+            [gl_cv_have_weak=no],
+            [dnl When cross-compiling, assume that only ELF platforms support
+             dnl weak symbols.
+             AC_EGREP_CPP([Extensible Linking Format],
+               [#ifdef __ELF__
+                Extensible Linking Format
+                #endif
+               ],
+               [gl_cv_have_weak="guessing yes"],
+               [gl_cv_have_weak="guessing no"])
+            ])
+        fi
+        ;;
+     esac
      dnl But when linking statically, weak symbols don't work.
      case " $LDFLAGS " in
        *" -static "*) gl_cv_have_weak=no ;;

[-- Attachment #4: threadlib-m4-31-cygwin-weak-no.patch --]
[-- Type: text/plain, Size: 2893 bytes --]

--- origsrc/bison-3.8.1/m4/threadlib.m4	2021-08-02 23:51:08.000000000 -0600
+++ src/bison-3.8.1/m4/threadlib.m4	2021-09-17 15:17:37.103525500 -0600
@@ -1,4 +1,4 @@
-# threadlib.m4 serial 31
+# threadlib.m4 serial 32
 dnl Copyright (C) 2005-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -84,38 +84,48 @@ AC_DEFUN([gl_WEAK_SYMBOLS],
   AC_REQUIRE([AC_CANONICAL_HOST])
   AC_CACHE_CHECK([whether imported symbols can be declared weak],
     [gl_cv_have_weak],
-    [gl_cv_have_weak=no
-     dnl First, test whether the compiler accepts it syntactically.
-     AC_LINK_IFELSE(
-       [AC_LANG_PROGRAM(
-          [[extern void xyzzy ();
+    [case "$host_os" in
+       cygwin*)
+         dnl On Cygwin 3.2.0 with gcc 10.2, the test below would succeed, but
+         dnl programs that use pthread_in_use() with weak symbol references
+         dnl crash miserably at runtime.
+         gl_cv_have_weak="guessing no"
+         ;;
+       *)
+         gl_cv_have_weak=no
+	 dnl First, test whether the compiler accepts it syntactically.
+	 AC_LINK_IFELSE(
+	   [AC_LANG_PROGRAM(
+	      [[extern void xyzzy ();
 #pragma weak xyzzy]],
-          [[xyzzy();]])],
-       [gl_cv_have_weak=maybe])
-     if test $gl_cv_have_weak = maybe; then
-       dnl Second, test whether it actually works. On Cygwin 1.7.2, with
-       dnl gcc 4.3, symbols declared weak always evaluate to the address 0.
-       AC_RUN_IFELSE(
-         [AC_LANG_SOURCE([[
+	      [[xyzzy();]])],
+	   [gl_cv_have_weak=maybe])
+	 if test $gl_cv_have_weak = maybe; then
+	   dnl Second, test whether it actually works. On Cygwin 1.7.2, with
+	   dnl gcc 4.3, symbols declared weak always evaluate to the address 0.
+	   AC_RUN_IFELSE(
+	     [AC_LANG_SOURCE([[
 #include <stdio.h>
 #pragma weak fputs
 int main ()
 {
   return (fputs == NULL);
 }]])],
-         [gl_cv_have_weak=yes],
-         [gl_cv_have_weak=no],
-         [dnl When cross-compiling, assume that only ELF platforms support
-          dnl weak symbols.
-          AC_EGREP_CPP([Extensible Linking Format],
-            [#ifdef __ELF__
-             Extensible Linking Format
-             #endif
-            ],
-            [gl_cv_have_weak="guessing yes"],
-            [gl_cv_have_weak="guessing no"])
-         ])
-     fi
+	     [gl_cv_have_weak=yes],
+	     [gl_cv_have_weak=no],
+	     [dnl When cross-compiling, assume that only ELF platforms support
+	      dnl weak symbols.
+	      AC_EGREP_CPP([Extensible Linking Format],
+		[#ifdef __ELF__
+		 Extensible Linking Format
+		 #endif
+		],
+		[gl_cv_have_weak="guessing yes"],
+		[gl_cv_have_weak="guessing no"])
+	     ])
+	 fi
+	 ;;
+     esac
      dnl But when linking statically, weak symbols don't work.
      case " $LDFLAGS " in
        *" -static "*) gl_cv_have_weak=no ;;

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

[Akim Demaille]

> Le 18 sept. 2021 à 15:22, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> a écrit :
> 
> Patch would not apply as included gnulib and bison threadlib.m4 appear to be from July and August.

FWIW, the last tarball I provided you with had a very recent gnulib.  The tarball below has

commit 7818455627c5e54813ac89924b8b67d0bc869146 (HEAD -> master, origin/master, origin/HEAD)
Author: Bruno Haible <bruno@clisp.org>
Date:   Fri Sep 17 22:22:50 2021 +0200

    threadlib: Avoid crashes in thread-related functions on Cygwin 3.2.0.
    
    Reported by Brian Inglis via Akim Demaille in
    <https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00063.html>.
    
    * m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
    Cygwin.

at its top.

https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.gz
https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.lz
https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.xz


Cheers!

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

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Brian Inglis wrote:
> Respun and applied patch successfully to glm4/threadlib.m4.

Did you regenerate the 'configure' script, and also do 'make distclean',
after patching threadlib.m4?

Find attached a new 'testdir-thread' package. When you configure and
build it (with './configure -C' and NO explicit setting of gl_cv_have_weak,
then "make && make check"), does it work? I.e. does it complete with just
one test failure (test-raise)?

Bruno

[-- Attachment #2: testdir-thread.tar.xz --]
[-- Type: application/x-xz-compressed-tar, Size: 270412 bytes --]

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

[Brian Inglis]

On 2021-09-18 09:10, Bruno Haible wrote:
> Brian Inglis wrote:
>> Respun and applied patch successfully to glm4/threadlib.m4.
> 
> Did you regenerate the 'configure' script, and also do 'make distclean',
> after patching threadlib.m4?
> 
> Find attached a new 'testdir-thread' package. When you configure and
> build it (with './configure -C' and NO explicit setting of gl_cv_have_weak,
> then "make && make check"), does it work? I.e. does it complete with just
> one test failure (test-raise)?

No - how do you regenerate a configure script, and how do you do a make 
distclean without a makefile generated?
I've only dealt with autotools used by upstream packages.

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

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

[Brian Inglis]

On 2021-09-18 10:15, Brian Inglis wrote:
> On 2021-09-18 09:10, Bruno Haible wrote:
>> Brian Inglis wrote:
>>> Respun and applied patch successfully to glm4/threadlib.m4.
>>
>> Did you regenerate the 'configure' script, and also do 'make distclean',
>> after patching threadlib.m4?
>>
>> Find attached a new 'testdir-thread' package. When you configure and
>> build it (with './configure -C' and NO explicit setting of 
>> gl_cv_have_weak,
>> then "make && make check"), does it work? I.e. does it complete with just
>> one test failure (test-raise)?
> 
> No - how do you regenerate a configure script, and how do you do a make 
> distclean without a makefile generated?
> I've only dealt with autotools used by upstream packages.

Similarly, what would be required to patch threadlib.m4 and have it be 
used in the bison configure and build, to avoid the configure redefinition?

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

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

[Brian Inglis]

On 2021-09-18 09:10, Bruno Haible wrote:
> Brian Inglis wrote:
>> Respun and applied patch successfully to glm4/threadlib.m4.
> 
> Did you regenerate the 'configure' script, and also do 'make distclean',
> after patching threadlib.m4?
> 
> Find attached a new 'testdir-thread' package. When you configure and
> build it (with './configure -C' and NO explicit setting of gl_cv_have_weak,
> then "make && make check"), does it work? I.e. does it complete with just
> one test failure (test-raise)?

I tried running make distclean in the build dir and it wiped all the 
files, before redoing the build. That seems to have done the trick.
The configure output now only really mentions weak in comments, the 
build completes with no issues, and the checks complete with just that 
failure.

I was sure I had wiped the bison build dir with `cygport ... finish` 
just before rerunning `cygport ... all check`, but I have redone that, 
with the respun patch for the bison threadlib.m4, and without explicit 
gl_cv_have_weak, the configure output now shows guessing no, configure 
and build worked, the examples and tests are building YACC/CC/CCLD 
without dumping, so I am hopeful it will now pass the tests.

Thanks very much for your help Bruno, in diagnosing the issue correctly, 
and providing the patch: I will ensure your patch comment gets prefixed 
into the respun bison gnulib patch.

And thanks Akim for getting Bruno involved to address the right area.

Cygwin bison users will be happy having the latest build available.

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

Re: rebuilding after modifying some .m4 files

[Bruno Haible]

Brian Inglis wrote:
> >> Respun and applied patch successfully to glm4/threadlib.m4.
> > 
> > Did you regenerate the 'configure' script, and also do 'make distclean',
> > after patching threadlib.m4?
> 
> No

That explains why it had no effect for you.

> - how do you regenerate a configure script, and how do you do a make 
> distclean without a makefile generated?

Take a look at a tutorial regarding the GNU Build System, e.g. [1].

To regenerate a configure script, run 'autoreconf' in the source directory.
When you do this, also do a 'make distclean' in the source directory,
and remove all build directories in which you ran '../configure ...'

To "make distclean" when no Makefile is there, run
  ./configure
  make distclean
This is the most reliable way to remove leftovers from previous builds.

Bruno

[1] https://www.softprayog.in/tutorials/understanding-gnu-build-system

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

[Bruno Haible]

Brian Inglis wrote:
> > Find attached a new 'testdir-thread' package. When you configure and
> > build it (with './configure -C' and NO explicit setting of gl_cv_have_weak,
> > then "make && make check"), does it work? I.e. does it complete with just
> > one test failure (test-raise)?
> 
> I tried running make distclean in the build dir and it wiped all the 
> files, before redoing the build. That seems to have done the trick.
> The configure output now only really mentions weak in comments, the 
> build completes with no issues, and the checks complete with just that 
> failure.

Thanks for the confirmation that the fix works!

Bruno

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

[Akim Demaille]

Hi Brian,

> Le 18 sept. 2021 à 19:04, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> a écrit :
> 
> Thanks very much for your help Bruno, in diagnosing the issue correctly, and providing the patch: I will ensure your patch comment gets prefixed into the respun bison gnulib patch.
> 
> And thanks Akim for getting Bruno involved to address the right area.
> 
> Cygwin bison users will be happy having the latest build available.

I did not see the confirmation that the last tarball I made did work on your system.

https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.gz
https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.lz
https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.xz

I might have missed it though.

Thanks Bruno, thanks Brian.

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

[Brian Inglis]

On 2021-09-20 21:25, Akim Demaille wrote:
> Le 18 sept. 2021 à 19:04, Brian Inglis a écrit :
>> Thanks very much for your help Bruno, in diagnosing the issue
>> correctly, and providing the patch: I will ensure your patch comment
>> gets prefixed into the respun bison gnulib patch.
>> And thanks Akim for getting Bruno involved to address the right area.
>> Cygwin bison users will be happy having the latest build available.

> I did not see the confirmation that the last tarball I made did work on your system.
> https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.gz
> https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.lz
> https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.1.29-5c106.tar.xz
> I might have missed it though.

Sorry Akim,

I thought it was understood as confirmed in my last message.

This month I am busy dealing with a number of maintained package upgrade 
build and test failures, and at least one other appears to also be due 
to an obscure gnulib upgrade, after years of upgrades with at most only 
the occasional package tweak required, requiring only basic knowledge of 
autotools and none of gnulib!
With each build requiring one or more hours for the package manager to 
configure && make && make VPATH install && make check locally, for each 
arch, then repeat for confirmation on the CI, it takes up a lot of free 
time.

Your interim release includes the gnulib threadlib.m4 patch, so I had to 
disable applying that, which is great.

Cygwin only needs the revert-autoconf-upgrade patch, until an 
experienced autotools user adopts the autotools as maintainer and 
provides upgrades.

The builds and tests run completely, and only the Doxygen tests fail, 
although the doc builds work: not a significant concern.

Thanks very much again to you both, the great help is appreciated.

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