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

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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