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

[Robert Baruch <autophile at zoominternet dot net>]

I think I'm completely screwed. There doesn't seem to be any way to get 
a backtrace if a program does an abort. Here's the stack dump from 
before, with asterisks marking what are supposed to be valid frames. 
Again, the double-star marks the innermost frame as reported by 
t.exe.stackdump.

> (gdb) x/120x $esp
> 0x22fca4:       0x77f5c534      0x77e7a62d      0x00000778      
> 0x00000000
> 0x22fcb4:       0x0022fccc      0x00000778      0x0000ea60      
> 0x0022fd30
> 0x22fcc4:       0x77f7d417      0x0022fccc      0xdc3cba00      
> 0xffffffff
> 0x22fcd4:       0x7ffdf000      0x7ffde000      0x00000014      
> 0x00000001
> 0x22fce4:       0x00000000      0x00000000      0x00000010      
> 0x0022fcb8
> 0x22fcf4:       0x0022fd4c      0x0022ff28      0x77e94809      
> 0x77e83ae0
> 0x22fd04:       0x00000000     *0x0022fd58      0x77e7ac21      
> 0x00000778
> 0x22fd14:       0x0000ea60      0x00000000      0x61073611      
> 0x00000778
> 0x22fd24:       0x0000ea60      0xffffffff      0x77f59037      
> 0x00000000
> 0x22fd34:       0x00240000      0x00000000      0x00244348      
> 0x0022fe2c
> 0x22fd44:       0x0000c000      0x77f5c014      0x00000000      
> 0x00000001
> 0x22fd54:       0x00000780     *0x0022fde8      0x61071c99      
> 0x00000780
> 0x22fd64:       0x00000001      0x00000000      0x00000000      
> 0x00000000
> 0x22fd74:       0x0022fd90      0x0000003f      0x00401324      
> 0x0000c000
> 0x22fd84:       0x0022fd90      0x0000003f      0x00000000      
> 0x61616161
> 0x22fd94:       0x61416141      0x61616161      0x61126ac0      
> 0x61616161
> 0x22fda4:       0x00000008      0x00000001      0x00000778      
> 0x00000001
> 0x22fdb4:       0x0022fdd0      0x0022fe38      0x00000006      
> 0x00000000
> 0x22fdc4:       0x00000001      0x0022fdd8      0x61078220      
> 0x00000000
> 0x22fdd4:       0x0a040008      0x0022fe18      0x00000006      
> 0x00000724
> 0x22fde4:       0x00000000     *0x0022fe38      0x6106f232      
> 0x00000000
> 0x22fdf4:       0x61416141      0x61616161      0x61078199      
> 0x61616161
> 0x22fe04:       0x61614161      0x41616161      0x00000000      
> 0x00000000
> 0x22fe14:       0x0a030000      0xffffff00      0x61078220      
> 0x0022fec0
> 0x22fe24:       0x00000000      0x0022fe98      0x00000006      
> 0x00000724
> 0x22fe34:       0x00000000    **0x0022fe88      0x6106f3b0      
> 0x00000724
> 0x22fe44:       0x00000006      0x0022fea8      0x0040120d      
> 0x00000000
> 0x22fe54:       0x00000000      0x0022fe68      0xfffefeff      
> 0x00000000
> 0x22fe64:       0x0022fe80      0x0a030000      0x00000000      
> 0x00000000
> 0x22fe74:       0x00000000      0x41414141      0x0022febc      
> 0x0022fec0


GDB has a "frame addr" command which supposedly sets the stack frame in 
case the current stack frame is bogus. Using that command does not help:

$ 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) bt
#0  0x7ffe0304 in ?? ()
#1  0x77f5c534 in ntdll!ZwWaitForSingleObject ()
#2  0x77e7a62d in WaitForSingleObjectEx ()
#3  0x00000778 in ?? ()
(gdb) frame 0x0022fe88
#0  0x00000000 in ?? () from
(gdb) bt
#0  0x7ffe0304 in ?? ()
#1  0x77f5c534 in ntdll!ZwWaitForSingleObject ()
#2  0x77e7a62d in WaitForSingleObjectEx ()
#3  0x00000778 in ?? ()
(gdb)

Oh well.

For fun, I'm attaching the verbose output from dumper, modified to show 
some of the registers in each thread.

Since I can't get the dumper/gdb combination to work, let's step back. 
Is there any way in cygwin to debug a program that dies when it calls 
abort()?

Thanks for any help,

--Rob

Attachment: dumper.txt.gz
Description: application/gzip

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