segfault on 32bit cygwin snapshot

[Corinna Vinschen]

On Mar  2 20:03, Takashi Yano via Cygwin wrote:
> On Mon, 1 Mar 2021 21:25:42 +0900
> Takashi Yano wrote:
> > On Mon, 1 Mar 2021 09:55:46 +0900
> > Takashi Yano wrote:
> > > On Sun, 28 Feb 2021 19:48:28 +0100
> > > Marco Atzeri wrote:
> > > > On 20.02.2021 23:29, Takashi Yano wrote:
> > > > > On Sat, 20 Feb 2021 22:01:38 +0100
> > > > > Marco Atzeri wrote:
> > > > >> MC using latest snapshot 32bit 2021-02-19 (and 2021-02-10)
> > > > >>
> > > > >> now fails at startup with
> > > > >>
> > > > >> Exception: STATUS_ACCESS_VIOLATION at eip=61083736
> > > > > 
> > > > > Thanks for the report. I found the cause of this issue.
> > > > > I will submit a patch to fix it.
> > > > > 
> > > > 
> > > > mc is now fine with 2021-02-22
> > > > 
> > > > but I found another issue
> > > > 
> > > >   $ /usr/bin/lilypond
> > > > GNU LilyPond 2.20.0
> > > > Segmentation fault (core dumped)
> > > > 
> > > > on 3.1.7 it works fine
> > > 
> > > I found this problem causes after the commit:
> > > 
> > > commit 532b91d24e9496c7988b2b1dda7fc0e8b161f782
> > > Author: Corinna Vinschen <corinna@vinschen.de>
> > > Date:   Mon Dec 14 12:29:23 2020 +0100
> > > 
> > >     Cygwin: Make sure newer apps get uname_x even when loading uname dynamically
> > > 
> > >     if an application built after API version 334 loads uname dynamically,
> > >     it actually gets the old uname, rather than the new uname_x.  Fix this by
> > >     checking the apps API version in uname and call uname_x instead, if it's
> > >     a newer app.
> > > 
> > >     Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
> > > 
> > > Reverting this commit solves the issue.
> > > 
> > > Corinna, could you please have a look?
> > 
> > The following check code does not work as expected if
> > newly build exe file is linked with old dll which calls
> > uname() as in this case.
> > 
> >   if (CYGWIN_VERSION_CHECK_FOR_UNAME_X)
> >     return uname_x (in_name);
> > 
> > Any idea?
> 
> Ping Corinna?

I have no idea how we could fix that, other than by rebuilding the DLLs
which call uname, too.  We can't check the Cygwin build of all DLLs an
executable is linked to.


Corinna