delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/08/21/22:17:30

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: Tue, 21 Aug 2001 22:17:17 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: serious problem with cygwin and winsock?
Message-ID: <20010821221717.A27371@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
Mime-Version: 1.0
User-Agent: Mutt/1.3.11i

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.

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.

Anyway, does anyone have any insight into either what could be causing my
first problem or how to fix the second?

cgf

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019