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.
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
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.
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
5 matches
Mail list logo
