serious problem with cygwin and winsock?

Corinna Vinschen
Wed Aug 22 00:08:00 GMT 2001

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()."

> 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...


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

More information about the Cygwin-developers mailing list