From:	shankar AT chromatic DOT com (Shankar Unni)
Subject:	Re: fork bugs (was: newbie)
22 Jan 1997 20:09:56 -0800 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<199701221644.IAA19114.cygnus.gnu-win32@hatchet.chromatic.com>
Original-To:	scottk AT utig DOT ig DOT utexas DOT edu (Scott Kempf)
Original-Cc:	gnu-win32 AT cygnus DOT com
In-Reply-To:	<199701211948.NAA28070@utig.ig.utexas.edu> from "Scott Kempf" at Jan 21, 97 01:48:21 pm
X-Mailer:	ELM [version 2.4 PL23]
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

Scott Kempf said:

> One more fork bug.  I has some problems with fork where
> I had an executable in . and one in /usr/local/bin which
> where two different versions of the same program.  Fork
> choose to spawn the wrong one and made quite a mess trying
> to copy in the data section.  I found the problem and
> removed the out dated executable from  /usr/local/bin.
> Later I decided to try to fix this bug, but I have been
> unable to recreate it.  If someone has a simple example
> of this bug I'd love to try to fix the problem.

Does the cygwin fork() try to find the executable using $PATH if
argv[0] is a relative path name? If so, then yes, I can see how you
can easily cause something like this to happen:

Consider

 PATH=xxx:/usr/local/bin:xxxxx:.

(i.e. /usr/local/bin in $PATH before ".").  

Now, you start up ./executable from some other process using

  execle("./executable", "executable", ....)

and executable tries to fork. Oops - it sees a path-less argv[0],
tries to look it up in $PATH, and gets the wrong one. 

-- 
Shankar Unni                                  shankar AT chromatic DOT com
Chromatic Research                            (408) 752-9488
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -