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

[Akim Demaille]

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

dummy-logs.tar.xz
Description: Binary data