DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:from:to:subject:date:message-id
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=y4Z25Z4qTK8JtGaFDXIjb9z9mofpz3aL/5eboAZB3ZqajclDq8Dfn
	K0j5hWcBWhvMtAG6/US6D3Q4tSF+83wadLUxT826/ClaQJVJ6HBL6iMhkGbOkzpO
	lfUpu6SCJ/jz1tYrVxdodt4bq2GlQSTmip0ozJzb8EEYLiM27cKKwg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Reply-To: <sbardwell AT lbmsys DOT com>
From: "Steven Bardwell" <SBardwell AT lbmsys DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: using spawn functions to avoid fork() errors -- FIXED
Date: Fri, 7 Feb 2014 08:31:23 -0500
Message-ID: <029d01cf2408$e9ecc3e0$bdc64ba0$@lbmsys.com>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> >> On 2/6/2014 8:50 AM, Steven Bardwell wrote:
> >>> Larry - thanks for the link to the source for the spawn() APIs.  It
> > works
> >>> perfectly on my 32-bit install (where, as it happens, the fork() issue
> >>> never shows up either).
> >>>
> >>> However, on my 64-bit install, the spawnv() call is returning with an
> >>> error -- 'No such file or  directory' -- when I try to spawn /bin/sh.
> >>> I have attached the output from 'strace' on this process. If you look
at
> >>> line 602, I think you can see where the exception gets generated. Can
> >>> you see what is going on? I tried to create a simple test program that
> >>> shows the problem, but (so far) they all work. Thanks.
> >>
> > I am still trying to create a simple example, but the fact that it works
on
> > the 32-bit
> > install inspired me to look again at the strace output, comparing the
> output
> > from
> > the install that works with the 64-bit strace output that shows the
> problem.
> >
> /bin/sh is crashing, for sure, but it's not clear to me why that would
> be the case.  It certainly has something to do with the way it's being
> invoked.  But whether that's the problem (i.e. GIGO) or whether there's
> something wrong on the Cygwin side that your usage is conveniently
> bringing to light, I can't say.  I'm assuming the former given your
> description so far.
> 
> --
> Larry
> 
I found  the problem that was causing the failure of child creation logic
on the 64-bit install but not on the 32-bit version:

in an effort to make the output from 'ps' more useful, my application was
over-writing the contents of argv[1] in the main process. This trick works
fine in many flavors of Unix (including Interix and Linux and 32-bit
Cygwin).
However, in Cygwin 64-bit, it somehow corrupts things such that the
child process created by fork() or spawnv() failed to load correctly. After
removing that 'feature,' both spawnv() as well as the original fork() logic
work without any problem.

I really appreciate everyone's looking into this. 

Steve


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple