serious problem with cygwin and winsock?

Christopher Faylor
Wed Aug 22 09:56:00 GMT 2001

On Wed, Aug 22, 2001 at 09:08:25AM +0200, Corinna Vinschen wrote:
>On Tue, Aug 21, 2001 at 10:17:17PM -0400, Christopher Faylor wrote:
>> I've been going crazy this last week trying to figure out a problem
>> with cygwin and rshd.  It is one of those problems that disappear if
>> you run strace or single step in gdb.
>> What happens is that rshd sometimes ends up passing a 0 as the first
>> argument to execle when it is supposed to be something like:
>> "bash", "-c", "ls", 0
>> or whatever.  In my scenario the "bash" is sometimes NULL.
>> One thing I noticed is that rshd uses the structure returned by getpwnam
>> after calling endpwent.  Anyone know if that is a valid thing to do?
>> After calling endpwent, rshd uses the pw_shell part of the structure.
>It's valid. endpwent() isn't defined to destroy some allocated
>datastructure. However, the latest developer snapshots could
>behave that way if /etc/passwd has changed in the meantime. :-(
>The problem is that the getpwXXX functions use the genuine
>datastructures allocated by read_etc_passwd() instead of copying
>the result into a save static buffer.  Two solutions:
>- Revert the `recognize changes to /etc/passwd (/etc/group)' patch.
>- Let all getpwXXX()/getgrXXX() functions copy their stuff into
>  a local static buffer. It could even be exactly one buffer per
>  file since SUSv2 states:
>    "The return value may point to a static area which
>     is overwritten by a subsequent call to getpwent(),
>     getpwnam() or getpwuid()."

It can't just be a local static buffer since we have to accomodate threads.

There are mechanisms in cygwin's thread structure for saving per-thread
buffers.  I haven't looked at them recently, though.

>> Another thing I've noticed is that older versions of rshd used to use
>> the result of a gethostbyname call after a fork.  This is where the
>> "serious" part of the problem enters in.  Apparently this call uses
>> memory that is not allocated again after a fork, so if you do a:
>> struct hostent *hp = gethostbyname ("foo");
>> if (fork() == 0)
>>     printf ("%s\n", hp->h_name);
>>                     ^^^^^^^^^^
>> hp will not point to valid memory since it hasn't been duplicated by the
>> fork.  *ouch*
>> The only way that I can think of to work around this is to wrap every single
>> wsock call that returns a static buffer or somehow know enough to copy the
>> data sections of non-cygwin DLLs.
>I looked into and there are only a hand full of functions concerned:
>I will add static buffers or appropriate allocation functions in the
>next days. Fortunately these functions are defined so that the
>allocated structure is recycled on the next call by the same process...

I'm concerned about the thread consequences, though.  static buffers and
threads don't usually mix well.


More information about the Cygwin-developers mailing list