help: dumper 1.10 not giving expected stack trace in gdb

Thu Jan 1 15:09:00 GMT 2004

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dumper.txt.gz
Type: application/gzip
Size: 1884 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20040101/ceaa6a5d/attachment.gz>
-------------- next part --------------
--
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/