[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison segv under Cygwin 64 at fatal-signal.c:318
From: |
Akim Demaille |
Subject: |
Re: bison segv under Cygwin 64 at fatal-signal.c:318 |
Date: |
Thu, 16 Sep 2021 06:17:36 +0200 |
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
- bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/12
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/12
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Akim Demaille, 2021/09/13
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/13
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/13
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/14
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Akim Demaille, 2021/09/14
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/15
- Re: bison segv under Cygwin 64 at fatal-signal.c:318,
Akim Demaille <=
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Bruno Haible, 2021/09/16
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/16
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/16
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/16
Message not available
- Message not available
- Message not available
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/18
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Akim Demaille, 2021/09/18
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Bruno Haible, 2021/09/18
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Brian Inglis, 2021/09/18
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Bruno Haible, 2021/09/18
- Re: bison segv under Cygwin 64 at fatal-signal.c:318, Akim Demaille, 2021/09/20