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 11D483861810 for ; Mon, 8 Mar 2021 11:07:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 11D483861810 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 daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 128B7fXf078676 for ; Mon, 8 Mar 2021 03:07:41 -0800 (PST) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.20]" via SMTP by m0.truegem.net, id smtpdmb0iLK; Mon Mar 8 03:07:38 2021 Subject: Re: segfault on 32bit cygwin snapshot From: Mark Geisert To: cygwin@cygwin.com 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> Message-ID: <7b34da67-7550-765b-3731-31b51b2a5df9@maxrnd.com> Date: Mon, 8 Mar 2021 03:07:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, 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 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: Mon, 08 Mar 2021 11:07:45 -0000 Following up to myself... Mark Geisert wrote: > 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: >>>>>> >>>>>>    https://cygwin.com/pipermail/cygwin-apps/2020-December/040765.html >>>>>> https://cygwin.com/pipermail/cygwin-developers/2020-December/012019.html >>>>>> >>>>>> 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 >>>>          2b9de0   2170  uname >>>>          2b9de8   2171  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 for >>> the record but am having some difficulty.  I'll reply again when I've got >>> 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 further > into the recent Python versions.  The fact that they had an explicit dlopen/dlsym > to get at uname(), but now they don't, troubles me. I want to be sure us Cygwin > folk aren't in an inadvertent "arms race" with the Python devs over the uname API > change.  Dunno why this didn't occur 15+ years ago, but here we are. > > I think it was in Python's Modules/posixmodule.c.  They're certainly using uname() > directly in their most recent builds.  But I believe that wasn't always the case, > even just a few months ago.  Let me dig for a day or two. Not to put too fine a point on it, but I now believe I hit the issue I reported due to my own corrupted build environment. Marco and Ken have both built recent Python packages on Cygwin 3.1.7 and proto-3.2.0 respectively, Ken having reverted the commit you're talking about (not sure about Marco). Both had success. I believe reverting that commit 532b91d24e9496 is the correct action to take. ..mark