Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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