From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by sourceware.org (Postfix) with ESMTPS id 1BF653951C10 for ; Fri, 5 Mar 2021 14:37:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1BF653951C10 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MAfQe-1lTECE3SBc-00B3T2 for ; Fri, 05 Mar 2021 15:37:50 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5742BA8060B; Fri, 5 Mar 2021 15:37:50 +0100 (CET) Date: Fri, 5 Mar 2021 15:37:50 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: segfault on 32bit cygwin snapshot Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <7480c946-8e02-aba2-c06f-6b39f630699f@gmail.com> <20210301095546.dce31a474bd0cec2c3518f87@nifty.ne.jp> <20210301212542.8b1749f92af62c01b008f25a@nifty.ne.jp> <20210302200308.62db4fe01f78fb35a538784f@nifty.ne.jp> <20210303185621.b048287526901af6a4c8200a@nifty.ne.jp> <00624789-7d57-4e80-26f0-a48e9893b6c9@maxrnd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 14:37:53 -0000 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