Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Sat, 1 Jan 2005 12:48:25 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Stackdump trace - problem and patch
Message-ID: <20050101174825.GB16231@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <000901c4efdf$7e29f180$0200000a AT agamemnon>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000901c4efdf$7e29f180$0200000a@agamemnon>
User-Agent: Mutt/1.4.1i

On Sat, Jan 01, 2005 at 03:54:23AM -0500, Jon A. Lambert wrote:
>I was having this difficulty debugging a crashed application.  I was using
>Cygwin environmental variable error_start to either call dumper or gdb.
>Both a core dump and invoking gdb didn't show anything relevant to
>my application.  I tried various means of examining and setting the
>registers in the stack to get to a frame that was within my app.  I have
>read the various messages on the list describing how to get to those
>frames.  It's rather tricky, and it availed me not.  Probably a personal
>problem. ;-)

Probably.  And, for that reason we're not going to be adding another
cygwin option.  There is little reason to provide workarounds like this
when the real fix would be either to fix the user or the application.

In particular, if dumper isn't providing a valid core dump, then it
should certainly be fixed.

Thanks for the effort provided in coming up with a patch, though,
regardless.

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/