Re: segfault on 32bit cygwin snapshot

[Mark Geisert <mark@maxrnd.com>]

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