Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Fri, 19 Jul 2002 22:26:57 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: cygwin hang problem
Message-ID: <20020720022657.GA4688@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <3D32FC00 DOT 5090108 AT hekimian DOT com> <20020719050925 DOT GA24259 AT redhat DOT com> <3D37F0E5 DOT 50F3669B AT yahoo DOT com> <20020719141242 DOT GB27697 AT redhat DOT com> <3D38949C DOT 3090200 AT hekimian DOT com> <20020720013040 DOT GA3445 AT redhat DOT com> <3D38C828 DOT 2050802 AT hekimian DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3D38C828.2050802@hekimian.com>
User-Agent: Mutt/1.3.23.1i

On Fri, Jul 19, 2002 at 10:17:12PM -0400, Joe Buehler wrote:
>Christopher Faylor wrote:
>
>>Why did you feel that you had to modify handle_exceptions to wait for
>>dumper?  Since dumper is invoked as a debugger, and your backtrace
>>showed that try_to_debug was invoked with waitloop == true, this code
>>should have been exercised:
>
>That was my change -- to invoke with waitloop == true.  At least in
>the snapshot I am using, the code goes like this:
>
>if (try_to_debug(0)) {
>	debugging = 1;
>	return 0;
>}
>
>I observed that "debugging" got quite high in value before
>dumper managed to attach, and I was concerned that who knows what
>had been done to the stack in the meanwhile.

Ah.  Ok.  In that case the intent is for the debugger to see the actual
place where the SEGV occurred.  So, there is a lot of spinning going on
after the debuger process is invoked.  It is supposed to spin, hitting
the same SEGV until the debugger is initialized and at the point where
the process has been attached to, the debugger will see the SEGV (or
whatever) at the location where the actual error occurred.  Otherwise,
the stack is pretty much guaranteed to be in an incorrect state since it
has exception information on it that will probably confuse gdb.

cgf