From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 886753857816 for ; Fri, 5 Mar 2021 22:55:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 886753857816 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: from localhost (mark@localhost) by m0.truegem.net (8.12.11/8.12.11) with ESMTP id 125Mtjcc080625 for ; Fri, 5 Mar 2021 14:55:45 -0800 (PST) (envelope-from mark@maxrnd.com) X-Authentication-Warning: m0.truegem.net: mark owned process doing -bs Date: Fri, 5 Mar 2021 14:55:45 -0800 (PST) From: Mark Geisert X-X-Sender: mark@m0.truegem.net To: cygwin@cygwin.com Subject: Re: segfault on 32bit cygwin snapshot In-Reply-To: Message-ID: References: <20210303185621.b048287526901af6a4c8200a@nifty.ne.jp> <20210304180534.7c3825e6ee989a2bf62f0652@nifty.ne.jp> <20210304205000.4ac34afe1a8b767ea2986291@nifty.ne.jp> <98df59b3-a139-03d2-c8c5-31ff4f8448ab@gmail.com> <625cb9d2-b6cc-3ada-eea9-44a5e73da17c@gmail.com> <72a86908-e150-2070-24f7-79ca82de9916@maxrnd.com> MIME-Version: 1.0 X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 22:55:50 -0000 Hi Corinna, On Fri, 5 Mar 2021, Corinna Vinschen wrote: > On Mar 5 01:11, Mark Geisert wrote: >> Marco Atzeri via Cygwin wrote: >>> On 04.03.2021 21:17, Marco Atzeri wrote: >>>> On 04.03.2021 16:17, Ken Brown via Cygwin wrote: >>>>> On 3/4/2021 6:50 AM, Takashi Yano via Cygwin wrote: >>>>>> On Thu, 4 Mar 2021 12:11:11 +0100 >>>>>> marco atzeri wrote: >>>>>>> I have no problem to patch Python to solve the issue, >>>>>>> but I have not seen evidence of the dlsym mechanism . >>>>>>> But of course I an NOT and expert in this field. >>>>>>> >>>>>>> If someone looking to the code can give me some hints, >>>>>>> I will appreciate >>>>>> >>>>>> I am also not sure where the dlsym() is used in python. >>>>>> At least, os.uname() works in python 3.8.7 and 2.7.18 in my >>>>>> environment even without that snippet. It seems that os.uname() >>>>>> does not use dlsym(). Do I overlook something? >>>>> >>>>> This all started because Mark reported a problem building python 3.8.= 3: >>>>> >>>>> =C2=A0=C2=A0 https://cygwin.com/pipermail/cygwin-apps/2020-December/0= 40765.html >>>>> https://cygwin.com/pipermail/cygwin-developers/2020-December/012019.h= tml >>>>> >>>>> It's strange that Marco never bumped into the problem. >>>>> >>>>> Ken >>>> >>>> I never built python using cygwin snapshots as Mark was trying to do, >>>> all my builds were using 3.1.7. >>>> >>>> Let me set a separate enviroment for building on latest snapshot >>> >>> I can not replicate with latest snapshot >>> >>> $ uname -svr >>> CYGWIN_NT-10.0-WOW 3.2.0s(0.340/5/3) 2021-03-01 15:42 >>> >>> nor in 64bit when building 3.8.8 >>> >>> For what I see the DLL is always using a proper import >>> from cygwin1.dll >>> >>> $ objdump -x libpython3.8.dll |grep uname >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2b9de0=C2=A0=C2=A0 2170=C2= =A0 uname >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2b9de8=C2=A0=C2=A0 2171=C2= =A0 uname_x >>> >>> the only thing not standard on my build system is a case sensitive >>> filesystem and mount >> >> I had concerns that I had somehow corrupted my build environment, and it= was >> Marco's successes that convinced me to reinstall 3.1.7 to recover a >> known-good environment. Then seeing Marco go ahead and release the >> different Python releases (yay!) I didn't investigate any further. >> >> I'm now trying to locate the os.uname usage of dlopen/dlsym again just f= or >> the record but am having some difficulty. I'll reply again when I've go= t >> it. > > Guys, > > if it turns out that we fixed a problem that doesn't actually is a > real-world problem, I'm wondering if we shouldn't just revert the Cygwin > patch we're talking about here (commit 532b91d24e9496) and be done with > it. > > Special casing dynamic loading of uname just to support some experimental > bordercase doesn't make much sense. In that case I'm all for "don't do > that"! That may well be the appropriate endpoint, but please let me dig a little= =20 further into the recent Python versions. The fact that they had an=20 explicit dlopen/dlsym to get at uname(), but now they don't, troubles me.= =20 I want to be sure us Cygwin folk aren't in an inadvertent "arms race" with= =20 the Python devs over the uname API change. Dunno why this didn't occur=20 15+ years ago, but here we are. I think it was in Python's Modules/posixmodule.c. They're certainly using= =20 uname() directly in their most recent builds. But I believe that wasn't=20 always the case, even just a few months ago. Let me dig for a day or two. Thanks, =2E.mark