segfault on 32bit cygwin snapshot
Fri Mar 5 09:18:08 GMT 2021
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,
More information about the Cygwin