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
X-Authentication-Warning:	slinky.cs.nyu.edu: pechtcha owned process doing -bs
Date:	Tue, 30 Dec 2003 21:39:33 -0500 (EST)
From:	Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To:	cygwin AT cygwin DOT com
To:	Robert Baruch <autophile AT zoominternet DOT net>
cc:	cygwin AT cygwin DOT com
Subject:	Re: help: dumper 1.10 not giving expected stack trace in gdb
In-Reply-To:	<3FF1F041.9010506@zoominternet.net>
Message-ID:	<Pine.GSO.4.56.0312302135360.18706@slinky.cs.nyu.edu>
References:	<3FF1F041 DOT 9010506 AT zoominternet DOT net>
MIME-Version:	1.0

On Tue, 30 Dec 2003, Robert Baruch wrote:

> Hi all,
>
> I've compiled a simple C program, t.c, via gcc-3.3.1, with -g:
>
> #include <stdio.h>
>
> int main(void)
> {
>   abort();
> }
>
> I've set CYGWIN='error_start=C:\cygwin\bin\dumper.exe'. So when I run
> the program, abort causes dumper to run, and I end up with a
> t.exe.stackdump file and a t.exe.core file.
>
> The stackdump file contains this:
>
> Stack trace:
> Frame     Function  Args
> 0022FD08  6106F232  (000009E4, 00000006, 0022FD78, 0040120D)
> 0022FD58  6106F3B0  (000009E4, 00000006, 0022FDA8, 6106F965)
> 0022FD68  6106F2FC  (00000006, 00000006, 0022FD98, 61003A31)
> 0022FDA8  6106F965  (0022FDC0, 610850F8, 610F063C, 00000000)
> 0022FDC0  00401073  (00000001, 0A041AE8, 0A040330, 61062452)
> 0022FF40  61005018  (610CFEE0, FFFFFFFE, 000007E4, 610CFE04)
> 0022FF90  610052ED  (00000000, 00000000, 00000001, 00000000)
> 0022FFB0  00401401  (00401050, 037F0009, 0022FFF0, 77E814C7)
> 0022FFC0  0040103C  (77F58A3A, 00000000, 7FFDF000, F359BCF0)
> 0022FFF0  77E814C7  (00401000, 00000000, 78746341, 00000020)
> End of stack trace
>
> However, when I run gdb 2003-09-20-cvs (cygwin-special) on the core
> file, I get this:
>
> $ gdb --core=t.exe.core
> GNU gdb 2003-09-20-cvs (cygwin-special)
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin".
> #0  0x7ffe0304 in ?? ()
> (gdb) where
> #0  0x7ffe0304 in ?? ()
> #1  0x77f5c534 in ntdll!ZwWaitForSingleObject ()
> #2  0x77e7a62d in WaitForSingleObjectEx ()
> #3  0x00000778 in ?? ()
>
> That doesn't look anything like the stack dump shown in the stackdump file.
>
> What am I missing? How can I get gdb to display the proper stack trace?
>
> I appreciate any help you can give.
>
> Thanks,
> --Rob

If I'm reading the code correctly, the stackdump file is generated from
the failed thread.  The core file contains the information about all
threads, with no info on what the current (failed) one is.  So, try
running 'info threads' in gdb, and then switch to each thread using
'thread N' until you find the one that crashed.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

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