On 2021-09-13 12:10, Achim Gratz wrote:
Brian Inglis writes:
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!
You only need to look at lib/fatal-signal.c and how that differs
between the working and non-working build as a first step. If there's
nothing obvious there, you need to look at the call chain that's
involved in the crash, of course.
There no changes near there, only later ensuring the lock is released on
malloc failure, but I am surprised that something so obvious still needs
dealt with!
Thanks for the hints and tips, I really appreciate and need them, as I
have had little experience dealing with GNU packages complex
infrastructure except where issues are obvious, and the resulting lack
of traceability.
I think I need to dig out the build commands and generate that module as
-E expanded source, maybe the whole tree, as it still looks as if the
gnulib macros expanding pthread_in_use to glthread_in_use manage to get
that defined elsewhere as int 1!
--
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.]
