Re: segfault on 32bit cygwin snapshot

[Takashi Yano <takashi.yano@nifty.ne.jp>]

Hi Corinna,

On Wed, 3 Mar 2021 12:00:25 +0100
Corinna Vinschen wrote:
> [Ping Mark Geisert]
> 
> On Mar  3 18:56, Takashi Yano via Cygwin wrote:
> > Hi Corinna,
> > 
> > On Tue, 2 Mar 2021 16:48:45 +0100
> > Corinna Vinschen wrote:
> > > On Mar  2 20:03, Takashi Yano via Cygwin wrote:
> > > > > 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.
> > 
> > I have checked all /usr/bin/*.dll in my cygwin installation and found
> > following dlls call uname() rather than uname_x().
> > [...]
> > Do you think rebuilding all of these (or maybe more) dlls is only
> > the solution? 
> 
> No, we could also drop the above code snippet.
> 
> Here's the problem: When we changed some datatypes in the early 2000s,
> the old entry points have been conserved for backward compatibility,
> while the new function using the new datatypes got a new name, e. g.,
> stat vs. _stat64.
> 
> Next, libcygwin.a gets changed so that a newly built executable (using
> the new datatypes as defined in the standard headers) calling stat is
> redirected to _stat64.
> 
> All is well for the next 15+ years or so.
> 
> Then we discover that the exact same mechanism fails to work for
> uname vs. the new uname_x in python.  What happened?
> 
> It turned out that python called uname dynamically Rather then just
> calling uname, it calls dlopen();dlsym("uname");
> 
> This actually fetches the symbol for uname, not the symbol for uname_x.
> The good old mechanism used for ages on standard function, fails as soon
> as the caller uses dynamic loading of symbols.  Surprise, surprise!
> It was just never taken into consideration that standard libc functions
> might be called dynamically, given it usually doesn't make sense.
> 
> Given that this affects *all* of these redirected functions, we're in a
> bit of a fix.  Fortunately, for all other functions this only affects 32
> bit Cygwin, because the 64 bit version never had this backward
> compatibility problem.
> 
> Therefore, uname vs. uname_x is the only function affecting 64 bit
> Cygwin as well, and that's why I added the above crude redirection only
> to uname in the first place.
> 
> So what we can do is this:
> 
> - Either all old DLLs calling uname must be rebuilt.
> 
> - Or we remove the above code snippet again and behave like for all
>   other redirected functions on 32 bit as well.  Python's os.uname is
>   broken, but all the affected DLL sstart working again.
> 
> Is there a way around that?  I'm not quite sure, so let's brain storm
> a bit, ok?
> 
> - One thing we could try is to remove the above code, but add a python
>   hack to dlsym instead.  This would let the "old" DLLs work again as
>   before and for python we could add a hack to dlsym, along these lines:
> 
>     if (CYGWIN_VERSION_CHECK_FOR_UNAME_X
>     	&& modulehandle == cygwin1.dll
> 	&& strcmp (symname, "uname"))
>       symname = "uname_x";
> 
> Thoughts?  Other ideas?

It sounds very reasonable to me to deal with it within dlsym(),
as the problem arises from the use of dlsym(). However, what
happens if newly built .exe is linked to old dll which calls
uname() via dlsym()? I am not sure whether there are such dlls.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>