Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
Message-ID: <009c01c4f0fc$92f2b160$0200000a@agamemnon>
From: "Jon A. Lambert" <jlsysinc AT alltel DOT net>
To: <cygwin AT cygwin DOT com>
References: <000901c4efdf$7e29f180$0200000a AT agamemnon> <20050101174825 DOT GB16231 AT trixie DOT casa DOT cgf DOT cx>
Subject: Re: Stackdump trace - problem and patch
Date: Sun, 2 Jan 2005 13:55:03 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Christopher Faylor wrote:
> On Sat, Jan 01, 2005 at 03:54:23AM -0500, Jon A. Lambert wrote:
>> 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.

Ah the user was looking to fix the application.  The difficulty I was 
running into is identical to the scenario Robert Baruch posted here:
http://www.cygwin.com/ml/cygwin/2003-12/msg01047.html

He was more concerned at getting the backtrace readable.  I'm more concerned 
with fixing my application fast.  If you look at his posted stackdump though 
you'll see it's definitely in userland, readable and more than enough 
information to solve the problem.  That is easily pinpoint the problem had 
it been a real application.

I used his solution here:
http://www.cygwin.com/ml/cygwin/2004-01/msg00066.html

His solution does work.  My problem is that when your application isn't a 
trivial test but farly large, you have to chase the $ebp up the stack not 
just twice like he did but dozens of times.  Or scan through it until you 
see something in your space.  Of course I noticed my stackdump trace, like 
his too, looked just fine.  The only problem was half the trace entries were 
in cygwinland and only eight were in userland, unfortunately in well tested 
and layered utility routines.  I needed only two more trace entries to 
pinpoint my problem.

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

That's okay.  I thought I'd get fancy and provide some user configuration 
options.  In any case 16 trace entries ain't enough for me, well because my 
application is a compiler/vm.

Even this would be more than helpful.
stackdump()
-  for (i = 0; i < 16 && thestack++; i++)
+  for (i = 0; i < 32 && thestack++; i++)

Anyway if not, I can always patch it there in everytime I upgrade.



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