X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4AD73B83.9060505@gmail.com> Date: Thu, 15 Oct 2009 16:10:59 +0100 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: fork failure? References: <4AD732C7 DOT 4020301 AT cwilson DOT fastmail DOT fm> In-Reply-To: <4AD732C7.4020301@cwilson.fastmail.fm> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Charles Wilson wrote: > Nothing. For all I can tell, the fork() fails to *actually* produce a > child process -- even though the *parent* seems to think one has been > created, and has a pid for the so-called child. Which doesn't actually > exist. > > Can anybody think of a reason that might cause this behavior? I'm using > stock cygwin-1.7.0-62... Child gets started long enough to communicate with parent but then dies subsequently, still in early init, but late enough that the parent process create retries don't kick in. Don't hang about; get strace or procmon straight on the case with this, find out definitively if that process actually does get created or not. Oh, and maybe try a --enable-debugging build and set CYGWIN_DEBUG so you can intercept it if it does get started. cheers, DaveK -- 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