From: shankar@chromatic.com (Shankar Unni)
Subject: Re: fork bugs (was: newbie)
22 Jan 1997 20:09:56 -0800
Approved: cygnus.gnu-win32@cygnus.com
Distribution: cygnus
Message-ID: <199701221644.IAA19114.cygnus.gnu-win32@hatchet.chromatic.com>
Content-Type: text
Original-To: scottk@utig.ig.utexas.edu (Scott Kempf)
Original-Cc: gnu-win32@cygnus.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@cygnus.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@chromatic.com
Chromatic Research                            (408) 752-9488
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".