Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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:	<3FF2ED39.9080003@zoominternet.net>
Date:	Wed, 31 Dec 2003 10:37:29 -0500
From:	Robert Baruch <autophile AT zoominternet DOT net>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: help: dumper 1.10 not giving expected stack trace in gdb
References:	<3FF1F041 DOT 9010506 AT zoominternet DOT net> <Pine DOT GSO DOT 4 DOT 56 DOT 0312302135360 DOT 18706 AT slinky DOT cs DOT nyu DOT edu> <3FF2414D DOT 8060507 AT zoominternet DOT net> <20031231063511 DOT GA2113 AT redhat DOT com>
In-Reply-To:	<20031231063511.GA2113@redhat.com>
X-IsSubscribed:	yes

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.
>
Hi Christopher,

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:

Stack trace:
Frame     Function  Args
0022FE38  6106F232  (00000DD4, 00000006, 0022FEA8, 0040120D)
0022FE88  6106F3B0  (00000DD4, 00000006, 0022FED8, 6106F965)
0022FE98  6106F2FC  (00000006, 00000006, 0022FEC8, 61003A31)
0022FED8  6106F965  (0022FEF0, 610850F8, 610F063C, 00000000)
0022FEF0  00401073  (00000001, 6160214C, 0A040330, 0022FF24)
0022FF40  61005018  (610CFEE0, FFFFFFFE, 000007E4, 610CFE04)
0022FF90  610052ED  (00000000, 00000000, 00000001, 00000000)
0022FFB0  00401401  (00401050, 037F0009, 0022FFF0, 77E814C7)
0022FFC0  0040103C  (00000001, 00000017, 7FFDF000, F3583CF0)
0022FFF0  77E814C7  (00401000, 00000000, 78746341, 00000020)
End of stack trace

The "Frame" column is a frame pointer, isn't it? I loaded t.exe into gdb 
and checked out some of the addresses via x/i. The functions look 
perfectly reasonable.

When I set error_start to dumper.exe, the very same program produces a 
core file which apparently does not correspond to the stackdump 
information at all.

So my question now is, why would dumper produce a "bad" core file, while 
without dumper, cygwin generates a "good" stackdump file?

Thanks for any help,

--Rob



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

- Raw text -