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: Fri, 14 Sep 2001 13:11:17 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Useful details about the Make SEGVs
Message-ID: <20010914131117.D2709@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20010912173945 DOT 25925 DOT qmail AT lizard DOT curl DOT com> <20010914002450 DOT B25486 AT redhat DOT com> <20010914170318 DOT 4862 DOT qmail AT lizard DOT curl DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20010914170318.4862.qmail@lizard.curl.com>
User-Agent: Mutt/1.3.21i

On Fri, Sep 14, 2001 at 01:03:18PM -0400, Jonathan Kamens wrote:
>BTW, I rememberd this time to check errno inside gdb, and gdb says
>it's 0.  If execvp() fails (which of course it must have, since the
>code after the execvp() is running, right?) but errno is 0, there's
>definitely something fishy going on.
>
>Any suggestions?

My original supposition about what was causing this was apparently wrong.
An all night make -j2 failed for me too.  Interestingly, though, it's not
in the same place as above.

I think that somehow the stack is getting corrupted.  I don't see any
way that read could be calling exec_command.  There must be something flaky
in vfork but I don't know why it isn't deterministic.  That means, it is
probably signal related.  Sigh.

Another theory that I had was that a vforked "process" was calling "vfork".
That won't work currently, so I modified vfork to call fork if it appears
to be called recursively.  Obviously that had no effect on the problem,
though.

cgf