Re: stack trace and breaking before crash

On 3/11/08, Brian Dessent <briandessent.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:cygwinbingdb.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-ar
chive.com/cygwincygwin.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 <briandessent.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:cygwinbindumper.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)

Taras D wrote:

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

I don't think you're doing anything wrong.  It looks like
the JIT
debugger code in Cygwin and/or dumper might need some
bugfixes.  The
reason that continuing works is that it simply retriggers
the fault
again at the same location where it faulted the first time. 
Apparently
at the point where gdb and/or dumper attaches to the
process, the
location of the fault is already lost and execution is
somewhere inside
the ntdll bowels in the exception handling code.

If you don't like the command prompt (note: not DOS!) you
can easily
write a simple wrapper executable that invokes whatever
debugger you
prefer... in fact you can put your debugger as the
error_start
parameter.  The only catch is that error_start has to name a
real
executable, it can't name a script or interpreter or batch
file.  And
you don't have control over the arguments passed, $1 is the
path to the
binary and $2 is the pid.

Brian