segfault on 32bit cygwin snapshot

Mark Geisert
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:
>>>       	&& 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,


More information about the Cygwin mailing list