This is the mail archive of the 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

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 ?? ()

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,


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

Unsubscribe info:
Problem reports:

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