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

[Brian Inglis]

[Originally submitted as https://savannah.gnu.org/support/?110539
but only one other report there and from 2004 so may not be used.]

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

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

bison-segv-cygwin-64.gdb
Description: Text document

bison-segv-cygwin-64-gdb.log
Description: Text document

bison-segv-cygwin-64-gdb.sh
Description: Text document