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: 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> <20210303185621 DOT b048287526901af6a4c8200a AT nifty DOT ne DOT jp> <00624789-7d57-4e80-26f0-a48e9893b6c9 AT maxrnd DOT com> MIME-Version: 1.0 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 AT cygwin DOT 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: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" 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