Re: stack trace and breaking before crash

["Taras D" <taras dot di at gmail dot com>]

On 3/11/08, Brian Dessent <brian@dessent.net> wrote:
>
> > inspection of the stack/variables/etc. The exception I'm getting is:
> > Exception: STATUS_ACCESS_VIOLATION at eip=610AE0E9. I've tried typing
>
> Oh, and that address range is inside the DLL so you won't get any
> symbols without first building Cygwin with debug symbols.  You can use
> the .dbg symbols file from the -src package, although the paths will be
> wrong so gdb won't be able to display source locations.
>
> Brian
>

First I executed the following command at my bash prompt:

export CYGWIN=error_start=c:\cygwin\bin\gdb.exe

When I run a program which deliberately tries to access address 0, gdb
starts in another window. However, the stack trace just shows junk:

(gdb) bt
#0  0x7c901231 in ntdll!DbgUiConnectToDbg ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x7c9507a8 in ntdll!KiIntSystemCall ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x00000005 in ?? ()
#3  0x00000004 in ?? ()
#4  0x00000001 in ?? ()
#5  0x186fffd0 in ?? ()
#6  0x00000246 in ?? ()
#7  0xffffffff in ?? ()
#8  0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#9  0x7c9507c8 in ntdll!KiIntSystemCall ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#10 0x00000000 in ?? ()
(gdb)

I'm not sure if this is where I require to build Cygwin with debug
symbols. The message at:
http://www.mail-archive.com/cygwin@cygwin.com/msg71279.html suggests
typing continue 'to see if gdb switches to the failing instruction'. I
tried this:

(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 8024.0x2324]
0x00401160 in printNull (pInt=0x0) at error.cpp:8
8               cout << *pInt << endl;
(gdb) bt
#0  0x00401160 in printNull (pInt=0x0) at error.cpp:8
#1  0x004011f2 in main () at error.cpp:18
(gdb)

This is working - I'm not quite sure why you have to 'continue', you
may be able to provide a reason.

On 3/11/08, Brian Dessent <brian@dessent.net> wrote:
> Set error_start to dumper to get a real core dump instead of the stack
> trace file.  Then load the core into gdb.

I tried this by executing:

export CYGWIN=error_start=c:\cygwin\bin\dumper.exe

at the bash prompt. After running the program the error.exe.core file
is produced. However loading this core into gdb doesn't provide much
info:

(gdb) core error.exe.core
warning: core file may not match specified executable file.
Loaded symbols for /home/Liz/c_code/error.exe
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll
#0  0x7c90eb94 in ntdll!LdrAccessResource
    () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) bt
#0  0x7c90eb94 in ntdll!LdrAccessResource ()
   from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x00000000 in ?? ()
(gdb)

What am I doing wrong here? I'd like to get this 'core' option working
as the other option starts gdb in a DOS command prompt, which prevents
you from using any other type of interface with gdb (emacs/gui/etc)