Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Wed, 22 Aug 2001 12:56:16 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: serious problem with cygwin and winsock?
Message-ID: <20010822125616.A371@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20010821221717 DOT A27371 AT redhat DOT com> <20010822090825 DOT H17561 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <20010822090825.H17561@cygbert.vinschen.de>; from vinschen@redhat.com on Wed, Aug 22, 2001 at 09:08:25AM +0200

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 net.cc and there are only a hand full of functions concerned:
>
>cygwin_inet_ntoa
>cygwin_getprotobyname
>cygwin_getprotobynumber
>cygwin_getservbyname
>cygwin_getservbyport
>cygwin_gethostbyname
>cygwin_gethostbyaddr
>
>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.

cgf