segfault on 32bit cygwin snapshot

Mark Geisert mark@maxrnd.com
Fri Mar 5 09:18:08 GMT 2021


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.

Shall I write up a patch and submit it?
Thanks & Regards,

..mark


More information about the Cygwin mailing list