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

[Brian Inglis]

On 2021-09-12 13:31, Achim Gratz wrote:
> Brian Inglis writes:
>> 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!

> Probably something messed up with the memory model somewhere?  Got some
> warnings about pointers wrapping or something like that?

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

> That's a strangely specific address…

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?

Suggested upstream to bug-bison.

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

> How did it link then in the first place?  However, Cygwin definitely is
> not a GLib based system, so if Bison tries to use these function it
> probably has some compatibility shims somewhere that implement them for
> systems that don't have them.

Thanks for that hint and pointer: bison includes regular updates from 
gnulib which are in a subproject repo not included, and includes the lib 
directory, also not included, other than their .gitignore files.

>> This could result from Cygwin being neither fish nor fowl: none of
>> BSD, Sun, Windows, or Linux, although I notice some __CYGWIN__
>> conditionals.

> Unless these have been upstreamed from Cygwin I'm often inclined to get
> rid of these and see what happens… :-}

GNU attempts to distinguish from Windows and Mingw.

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

> Well, since you already know where the SEGV hits: what is the diff to the
> working 3.7.6 version? The sources for this get generated, so you need
> to check the build directories.

Worse, as neither gnulib/ nor lib/ sources are included in the repo, 
except for their .gitignore files, and only /lib in the tarball, I can 
only compare the 1.5MB of diffs on 36000 lines, which also span internal 
versions 3.7.90 and 3.7.91, and hope that I can spot something relevant!

I also have to check https://git.sv.gnu.org/gitweb/?p=gnulib.git for the 
relevant changed lib headers and sources about the right timeframe!

I'm hoping the maintainers may have some time to look and maybe remember 
what they did in their "gnulib update" commits over the last six months 
that might result in the observed effect.

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