X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C85393952DBE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1614769284;
	bh=qi09AeBAT8Ry3WTxb8FUXpRhS2buP7353vGvk0l6FmI=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=E5H9gAp12pBjZe7LLOuvkQ4YmIL0BSuPJ84O3gdPfbzWCdwYxAIO/xi7AMdj3sE6a
	 AAqQU70hN6SQNbwtXUyZOxC2Zr+HfyBk2vIT5jItnqpz+CFa0kOeHdLP9n3q4/K2DD
	 fp0M2C8Zg2i5/u4DVONzvPHqqXKa1cdgv+Zq3BwQ=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 345893861893
Date: Wed, 3 Mar 2021 12:00:25 +0100
To: cygwin AT cygwin DOT com
Subject: Re: segfault on 32bit cygwin snapshot
Message-ID: <YD9sSea32T7GqlJr@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com, Mark Geisert <mark AT maxrnd DOT com>
References: <9d7b9dc2-cb92-498b-7655-e9c618114c87 AT gmail DOT com>
 <20210221072954 DOT db2dcbd523ed366e4dfcb0d0 AT nifty DOT ne DOT jp>
 <7480c946-8e02-aba2-c06f-6b39f630699f AT gmail DOT com>
 <20210301095546 DOT dce31a474bd0cec2c3518f87 AT nifty DOT ne DOT jp>
 <20210301212542 DOT 8b1749f92af62c01b008f25a AT nifty DOT ne DOT jp>
 <20210302200308 DOT 62db4fe01f78fb35a538784f AT nifty DOT ne DOT jp>
 <YD5eXbxBWbUUSwcM AT calimero DOT vinschen DOT de>
 <20210303185621 DOT b048287526901af6a4c8200a AT nifty DOT ne DOT jp>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20210303185621.b048287526901af6a4c8200a@nifty.ne.jp>
X-Provags-ID: V03:K1:Eqp7KU3fgTUcoklgHMTLS4XEcymttxpt/qUbTQ2pzhiArVRvk5d
 o/9nKswBNKWGnMyIFAmgSKU8wt+/QafTl7VQb2910oUxrwPrBTHH7GodoM0SPYxL0+/ZLpB
 YDfx6nVBAKxIXJnQAKxtafILM6lZN8hrcAm/kp2oRA/l5FFxUOtNK1xyabF1uG7ci7Q9WLz
 J2lepdmIRR5Qvq7SZIVrw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:upJxRkW+TMY=:41JkOwJPml/TV3Dx9kPqOW
 9yyI9yhqX68z2JCTGvEftnW6t24hnuN/uIfvXg0oQOHyIqilCY1OnO1wzghOId1Q78p0hBQ9n
 OLuQ9PQ36Zt5lGshedjXT4e0inW5g78rULubLXLJjlqVLXvvC2kHBfEEmxE2gC8yeOdFrorGE
 hKfQmFCroSiUuznCCFXyZa/U3fsEsS2FzEJvan0IXRmGnxKCZBnfCjRPWzCxORFWTq7s4FhHZ
 6xK452Wyw0kLH3Z+/mvgIiBcaOkmQqpXAsv+S+yrq8gZOsT6ttEN4CrjR688PWPLA8ZqB+ehM
 YpwQcwLX5CPL43a1aaNnIa2Rf712UQobOPYR2+RMXJGDOqHXcr9BnHN0+AOJSNNN9yb+7zutB
 /T4W4fDNgHCLOf4u3K/iWcXN5Id6wRhgH1NzDCPsOJBSgu+1Ab13ucDNWhlNAGzjsimRZrQzK
 QxLF9O3dM0Y1zB1KrTqj5s9QA+bSuZyUrlKvFPjaL4BfVANBBb8n
X-Spam-Status: No, score=-101.4 required=5.0 tests=BAYES_00,
 GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>,
        Mark Geisert <mark AT maxrnd DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

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


Thanks,
Corinna
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple