X-Spam-Check-By: sourceware.org
Date: Sat, 22 Apr 2006 19:12:06 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: emacs debugging conundrum
Message-ID: <20060422231206.GB7953@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <444AA754 DOT 1080502 AT byu DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <444AA754.1080502@byu.net>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Sat, Apr 22, 2006 at 03:59:48PM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Any ideas on how I should go about debugging a core dump, when the dump
>doesn't occur under the debugger?  Is it more likely to be a cygwin bug,
>or an app bug?  I am experimenting with CVS emacs, and the build process
>fails when it gets to this command line (I've tried with both 1.5.19 and
>the latest snapshot):
>
>$ EMACSLOADPATH=/home/eblake/emacs/lisp ../src/bootstrap-emacs.exe -batch
>- --no-site-file --multibyte -f batch-byte-compile-if-not-done
>~/emacs/lisp/emacs-lisp/byte-opt.el
>Compiling /home/eblake/emacs/lisp/emacs-lisp/byte-opt.el
>Fatal error (6)*** starting debugger for pid 1996, tid 3732
>*** continuing pid 1996 from debugger call (1)
>Aborted (core dumped)

This indicates that it's dying in "abort".  So, set
error_start=c:/cygwin/bin/gdb.exe and, when the debugger pops up, set a
breakpoint just before abort returns (at the do_exit?) and let the
debugger continue.  The stack trace may make more sense from that point
especially since I just modified abort so that it doesn't use the cygwin
signal processing front-end -- that always screws up a backtrace from
a cygwin function.

cgf

--
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/