This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: help: dumper 1.10 not giving expected stack trace in gdb


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@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]