This is the mail archive of the
mailing list for the Cygwin project.
Re: help: dumper 1.10 not giving expected stack trace in gdb
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Robert Baruch <autophile at zoominternet dot net>
- Cc: cygwin at cygwin dot com
- Date: Tue, 30 Dec 2003 21:39:33 -0500 (EST)
- Subject: Re: help: dumper 1.10 not giving expected stack trace in gdb
- References: <3FF1F041.email@example.com>
- Reply-to: cygwin at cygwin dot com
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)
> 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
> 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.
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.
|\ _,,,---,,_ firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ email@example.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