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

[Achim Gratz <Stromeko@nexgo.de>]

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