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