Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Wed, 31 Dec 2003 12:02:24 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: help: dumper 1.10 not giving expected stack trace in gdb Message-ID: <20031231170224.GA3881@redhat.com> Mail-Followup-To: cygwin AT cygwin DOT com References: <3FF1F041 DOT 9010506 AT zoominternet DOT net> <3FF2414D DOT 8060507 AT zoominternet DOT net> <20031231063511 DOT GA2113 AT redhat DOT com> <3FF2ED39 DOT 9080003 AT zoominternet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FF2ED39.9080003@zoominternet.net> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com On Wed, Dec 31, 2003 at 10:37:29AM -0500, Robert Baruch wrote: >Christopher Faylor wrote: >>The core dump occurred in a function which does not have a frame >>pointer. This screws up stack dumps on x86 systems. There isn't >>really much that you can do about this. > >Thanks for the reply. I guess what I don't understand is, if I don't >set error_start to dumper, I get what appears to be a nice stack trace >in the t.exe.stackdump file: It's an unfortunate side effect of the way dumper works. The dumping process is paused waiting for a debugger (in this case dumper.exe) to connect. The routine that is used to pause is frameless. The stack is still available for inspection via something like 'x/100x $esp' but the stack trace is often munged in this scenario. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/