Hi all,
I have a suboptimal solution for getting a good stack trace in gdb.
First, DO NOT use dumper as the error_start program. Set
CYGWIN='error_start=C:\windows-path-to-gdb\gdb.exe'.
When an abort occurs, gdb will start.
Next, do info thread to find all the threads. Chances are the aborted
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)
Christopher Faylor wrote:
It's an unfortunate side effect of the way dumper works. The dumping
process is paused waiting for a debugger (in this case dumper.exe) to
connect. The routine that is used to pause is frameless. The stack is
still available for inspection via something like 'x/100x $e
Christopher Faylor wrote:
The core dump occurred in a function which does not have a frame pointer.
This screws up stack dumps on x86 systems. There isn't really much that
you can do about this.
Hi Christopher,
Thanks for the reply. I guess what I don't understand is, if I don't set
error_start
Igor Pechtchanski wrote:
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 us
Hi all,
I've compiled a simple C program, t.c, via gcc-3.3.1, with -g:
#include
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 stac
6 matches
Mail list logo
