serious problem with cygwin and winsock?

Christopher Faylor
Wed Aug 22 11:16: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()."

I don't want to revert your change or implement a static buffer right

I don't see any reason to reread the passwd file on a call to endpwent,
though.  Is there any reason to do this?  Would liminating the

  if (passwd_state  <= initializing)
    read_etc_passwd ();

"solve" any potential problem like this?

FWIW, I can't duplicate the problem anymore.  Sigh.  Maybe it was an
early week problem or something.


More information about the Cygwin-developers mailing list