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

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

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

Anyone seen these kinds of issues before? Also submitted to bug-bison.

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

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

[-- Attachment #2: bison-segv-cygwin-64.gdb --]
[-- Type: text/plain, Size: 1046 bytes --]

set logging file bison-segv-cygwin-64-gdb.log
set logging overwrite on
set logging on
break main
break /mnt/c/Users/bwi/src/cygwin/bison/bison-3.8.1-1.x86_64/src/bison-3.8.1/lib/main.c:30
break output_skeleton
break /mnt/c/Users/bwi/src/cygwin/bison/bison-3.8.1-1.x86_64/src/bison-3.8.1/src/output.c:903
break /mnt/c/Users/bwi/src/cygwin/bison/bison-3.8.1-1.x86_64/src/bison-3.8.1/src/output.c:785
break create_pipe_bidi
break create_pipe
break /mnt/c/Users/bwi/src/cygwin/bison/bison-3.8.1-1.x86_64/src/bison-3.8.1/lib/spawn-pipe.c:475
break block_fatal_signals
break /mnt/c/Users/bwi/src/cygwin/bison/bison-3.8.1-1.x86_64/src/bison-3.8.1/lib/fatal-signal.c:316
break /mnt/c/Users/bwi/src/cygwin/bison/bison-3.8.1-1.x86_64/src/bison-3.8.1/lib/fatal-signal.c:318
break /mnt/c/Users/bwi/src/cygwin/bison/bison-3.8.1-1.x86_64/src/bison-3.8.1/lib/fatal-signal.c:320
run -o y.tab.c --defines -Werror -Wall,dangling-alias --report=all --no-lines bison-3.8.1-1.x86_64/src/bison-3.8.1/examples/c/bistromathic/parse.y
break pthread_mutex_lock
disable 13

[-- Attachment #3: bison-segv-cygwin-64-gdb.log --]
[-- Type: text/plain, Size: 4221 bytes --]

Breakpoint 1 at 0x100464b60: file /usr/src/debug/bison-3.8.1-1/src/main.c, line 65.
Breakpoint 2 at 0x100464b78: file /usr/src/debug/bison-3.8.1-1/src/main.c, line 67.
Breakpoint 3 at 0x10041d140: file /usr/src/debug/bison-3.8.1-1/src/output.c, line 722.
Breakpoint 4 at 0x100422168: file /usr/src/debug/bison-3.8.1-1/src/output.c, line 903.
Breakpoint 5 at 0x10041d2a7: file /usr/src/debug/bison-3.8.1-1/src/output.c, line 785.
Breakpoint 6 at 0x100457960: file /usr/src/debug/bison-3.8.1-1/lib/spawn-pipe.c, line 617.
Breakpoint 7 at 0x100457100: file /usr/src/debug/bison-3.8.1-1/lib/spawn-pipe.c, line 147.
Breakpoint 8 at 0x1004574ce: file /usr/src/debug/bison-3.8.1-1/lib/spawn-pipe.c, line 475.
Breakpoint 9 at 0x10044ea50: file /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c, line 315.
Breakpoint 10 at 0x10044ea54: file /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c, line 316.
Breakpoint 11 at 0x10044ea54: file /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c, line 318.
Breakpoint 12 at 0x10044ea74: file /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c, line 320.
[New Thread 6868.0x1884]
[New Thread 6868.0x1bc8]
[New Thread 6868.0x22f8]
[New Thread 6868.0x2a38]

Thread 1 "bison" hit Breakpoint 1, main (argc=9, argv=0xffffcb70) at /usr/src/debug/bison-3.8.1-1/src/main.c:65
Breakpoint 13 at 0x1801670f0: pthread_mutex_lock. (2 locations)
Continuing.

Thread 1 "bison" hit Breakpoint 2, main (argc=9, argv=0xffffcb70) at /usr/src/debug/bison-3.8.1-1/src/main.c:67
Continuing.

Thread 1 "bison" hit Breakpoint 4, output () at /usr/src/debug/bison-3.8.1-1/src/output.c:903
903	  output_skeleton ();
Continuing.

Thread 1 "bison" hit Breakpoint 3, output_skeleton () at /usr/src/debug/bison-3.8.1-1/src/output.c:722
722	{
Continuing.

Thread 1 "bison" hit Breakpoint 5, output_skeleton () at /usr/src/debug/bison-3.8.1-1/src/output.c:785
785	    pid = create_pipe_bidi ("m4", m4, argv,
Continuing.

Thread 1 "bison" hit Breakpoint 6, create_pipe_bidi (progname=progname@entry=0x10046c418 <__func__.2+600> "m4", 
    prog_path=prog_path@entry=0x100468643 <argmatch_warning_docs+2275> "/usr/bin/m4", 
    prog_argv=prog_argv@entry=0xffffc990, directory=directory@entry=0x0, null_stderr=null_stderr@entry=false, 
    slave_process=slave_process@entry=true, exit_on_error=exit_on_error@entry=true, fd=fd@entry=0xffffc988)
    at /usr/src/debug/bison-3.8.1-1/lib/spawn-pipe.c:617
617	{
Continuing.

Thread 1 "bison" hit Breakpoint 7, create_pipe (progname=progname@entry=0x10046c418 <__func__.2+600> "m4", 
    prog_path=prog_path@entry=0x100468643 <argmatch_warning_docs+2275> "/usr/bin/m4", 
    prog_argv=prog_argv@entry=0xffffc990, directory=directory@entry=0x0, pipe_stdin=pipe_stdin@entry=true, 
    pipe_stdout=pipe_stdout@entry=true, prog_stdin=prog_stdin@entry=0x0, prog_stdout=prog_stdout@entry=0x0, 
    null_stderr=null_stderr@entry=false, slave_process=slave_process@entry=true, 
    exit_on_error=exit_on_error@entry=true, fd=fd@entry=0xffffc988)
    at /usr/src/debug/bison-3.8.1-1/lib/spawn-pipe.c:147
147	{
Continuing.

Thread 1 "bison" hit Breakpoint 8, create_pipe (progname=progname@entry=0x10046c418 <__func__.2+600> "m4", 
    prog_path=prog_path@entry=0x100468643 <argmatch_warning_docs+2275> "/usr/bin/m4", 
    prog_argv=prog_argv@entry=0xffffc990, directory=directory@entry=0x0, pipe_stdin=pipe_stdin@entry=true, 
    pipe_stdout=pipe_stdout@entry=true, prog_stdin=prog_stdin@entry=0x0, prog_stdout=prog_stdout@entry=0x0, 
    null_stderr=null_stderr@entry=false, slave_process=slave_process@entry=true, 
    exit_on_error=exit_on_error@entry=true, fd=fd@entry=0xffffc988)
    at /usr/src/debug/bison-3.8.1-1/lib/spawn-pipe.c:475
475	      block_fatal_signals ();
Continuing.

Thread 1 "bison" hit Breakpoint 9, block_fatal_signals () at /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c:315
315	{
Continuing.

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

[-- Attachment #4: bison-segv-cygwin-64-gdb.sh --]
[-- Type: text/plain, Size: 223 bytes --]

gdb -d bison-3.8.1-1.x86_64/src/bison-3.8.1/src -d bison-3.8.1-1.x86_64/src/bison-3.8.1/lib -d bison-3.8.1-1.x86_64/src/bison-3.8.1/lib/glthread -r -ex 'source bison-segv-cygwin-64.gdb' bison-3.8.1-1.x86_64/build/src/bison

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

[Achim Gratz]

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…

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

> 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… :-}

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


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

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

[Achim Gratz]

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

[Brian Inglis]

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