delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2021/03/05/09:38:00

X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6953839960CF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
s=default; t=1614955075;
bh=nD/YJJFSE4aOYADReGtJyuyZVITqthOYr0q78RaY0x0=;
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=ZQvsWRnnOXNmEDKe32MqUzAUeS8wf6BDFkdTQetQAq3H7jBJKJKBFe2esPnX8VGJ4
7Rx3wggotEeMXRtg43Zb9qqSWLjPcFjv2x3jk9SiYqfMUaC8PC20YT4eEpEy/PG6j3
QIQF8Q+y10eKRGVD/P++Zl1bcVspcf814S77nCBc=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1BF653951C10
Date: Fri, 5 Mar 2021 15:37:50 +0100
To: cygwin AT cygwin DOT com
Subject: Re: segfault on 32bit cygwin snapshot
Message-ID: <YEJCPu8RmtOv8Z5B@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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>
<YD9sSea32T7GqlJr AT calimero DOT vinschen DOT de>
<e15e6d1f-7680-8f80-871e-0d224a3ed682 AT maxrnd DOT com>
<YEEGw4P+vtzejGOv AT calimero DOT vinschen DOT de>
<00624789-7d57-4e80-26f0-a48e9893b6c9 AT maxrnd DOT com>
MIME-Version: 1.0
In-Reply-To: <00624789-7d57-4e80-26f0-a48e9893b6c9@maxrnd.com>
X-Provags-ID: V03:K1:zng4VASjAIc3n05bbrazMy512wFSSgeWCl13i4RBRubQ/MftRdq
SG43ut4Q2GCGwm4lOLIcsm5fv7QnPGqMIqzB5U2CkEBGAE3XMXjkhSE/+qk2RfKXZMiV6cY
GGPJKVoyjFXTtwEGknMU/je+oAAZ4zx3aa8uOs2lotMJL+HjhMTS/lWvTVNaGhtZdNqZgdT
8ZCS0p19gdycQGCejj2HQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:q5YNIklhUw0=:l2GocvTMKZV08v0huOd6j2
wKhfPMsrxPEFpYhNKNErb+WfypxVH1zNYHkrq8DUGdw1QqB7JcUFQ0VfyRCG1aeHzdF0kMLrr
/Jih2QkxgkMEWqhDjh6eXaQCs7CYH9Bt4xbG9Isu9nhs2PcpMCdhs1MRKYLoMQuxhlEyL9Nf9
0RF1EAcdU83k15we/cU/Img3SRGE3Nq3oSKQ+Y5HwUbKCWpz0lRLusuSAXBNKm/bVXqYkOIO6
TnsAuGP1OpbpDQvt4oYG/0BbjVxH/tiEShe6PGuiakzCto5bJ4dU62AgYc7Y9Z7E3O4QWALSL
yv4SIzbj6+SfST6+CRu9YwMFP2GiEbw2oJvp7xvXUboRGE99VmY2OsVzay5UB39mOxfHvMA9K
h+aAjyz6EfMO+JI0exyGJ95rAvrGdYJSOLrDlW2e+OlMA/QsjpvTLx3IaROlk4pzzWFwXqMcf
5NPF/YC9MA==
X-Spam-Status: No, score=-101.1 required=5.0 tests=BAYES_00,
GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, 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
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>
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

On Mar  5 01:18, Mark Geisert wrote:
> Hi Corinna,
> 
> Corinna Vinschen via Cygwin wrote:
> > On Mar  4 01:05, Mark Geisert wrote:
> > > Corinna Vinschen via Cygwin wrote:
> > > > 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?
> > > 
> > > That's a sly fix, but it seems that it would do the job.  That's good!
> > > 
> > > On a different tack, I was thinking about how run time code could tell the
> [...somewhat of a dead-end tangent elided...]
> > However, it's not clear how this fixes the actual problem.  We just
> > don't have a way to know what size the caller expects.
> > 
> > Having version or size info in structs like the Win32 API does in a
> > couple of cases makes a lot more sense now...
> 
> Indeed.  I like your dlsym proposal, but I would code the "modulehandle ==
> cygwin1.dll" first as it's less likely to be true than the version check.
> 
> I think "the above code" you mentioned still needs to be retained to deal
> with old exes calling uname directly and needing the old version.

To the contrary.  That code was only required to deal with *new*
executables calling uname via the old entry point, because they called
dlopen/dlsym("uname").  Given this is handled in dlsym with my above
proposal, that addition in uname should go away.  After all, it's the
reason for the DLL crashes we're talking about here.


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019