stack trace and breaking before crash

stack trace and breaking before crash

[Taras D]

Hi everyone,

I have two questions:

1) A program that crashes is writing a stack trace. However, the stack
trace is in heaxadecimal. Is there anyway of replacing the hexadecimal
numbers with symbols?

2) Is it possible to get gdb to break before the program crashes? In
VS 2003, the program breaks execution before the crash allowing
inspection of the stack/variables/etc. The exception I'm getting is:
Exception: STATUS_ACCESS_VIOLATION at eip=610AE0E9. I've tried typing
in bt after the crash occurs but the output doesn't seem to be a stack
trace of the running program.

I'm running gdb on cygwin.

Thanks

Taras

Re: stack trace and breaking before crash

[Andreas Schwab]

"Taras D" <taras.di@gmail.com> writes:

> 1) A program that crashes is writing a stack trace. However, the stack
> trace is in heaxadecimal. Is there anyway of replacing the hexadecimal
> numbers with symbols?

Try addr2line.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: stack trace and breaking before crash

[Brian Dessent]

Taras D wrote:

> 1) A program that crashes is writing a stack trace. However, the stack
> trace is in heaxadecimal. Is there anyway of replacing the hexadecimal
> numbers with symbols?

Set error_start to dumper to get a real core dump instead of the stack
trace file.  Then load the core into gdb.

> 2) Is it possible to get gdb to break before the program crashes? In
> VS 2003, the program breaks execution before the crash allowing
> inspection of the stack/variables/etc. The exception I'm getting is:
> Exception: STATUS_ACCESS_VIOLATION at eip=610AE0E9. I've tried typing
> in bt after the crash occurs but the output doesn't seem to be a stack
> trace of the running program.

Set error_start to gdb and you will be taken to the point of the
exception when it occurs.

Brian

Re: stack trace and breaking before crash

[Brian Dessent]

Taras D 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

Re: stack trace and breaking before crash

[Taras D]

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)

Re: stack trace and breaking before crash

[Brian Dessent]

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

Re: stack trace and breaking before crash

[Daniel Jacobowitz]

On Tue, Mar 11, 2008 at 10:45:08AM -0700, Brian Dessent wrote:
> 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.

Try info threads?  IIRC the debug connection is the "current" thread,
and the app is otherwise in a suspended thread.

-- 
Daniel Jacobowitz
CodeSourcery

Re: stack trace and breaking before crash

[Brian Dessent]

Daniel Jacobowitz wrote:

> Try info threads?  IIRC the debug connection is the "current" thread,
> and the app is otherwise in a suspended thread.

Yes, that's the reply I had typed out at first but then I tried it to
make sure and all three threads are off in ntdll somewhere.

Brian

Re: stack trace and breaking before crash

[Taras D]

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

This worked on my simple test app, but it causes my actual app to hang
(as was mentioned in the link that I posted). I think I will conclude
that gdb has some issues under cygwin, and move onto another tool
(unfortunately).

Thanks for your help anyway - it did teach me a few things :)