gdb attach to process to produce stacktrace

Christopher Faylor
Wed Sep 20 14:48:00 GMT 2006

On Wed, Sep 20, 2006 at 07:06:45AM -0700, Hans Horn wrote:
>for quite some time I was trying to figure out (e.g. 
> how to attach gdb 
>to a process in order to produce a useful stacktrace.
>All attempts however produced something useless like the following:
>[Switching to thread 1096.0x7f4]
>* 4 thread 1096.0x7f4  0x7c901231 in ntdll!DbgUiConnectToDbg () from 
>  3 thread 1096.0xce0  0x7c90eb94 in ntdll!LdrAccessResource () from 
>  2 thread 1096.0x8ec  0x7c90eb94 in ntdll!LdrAccessResource () from 
>  1 thread 1096.0xc40  0x7c90eb94 in ntdll!LdrAccessResource () from 
>[Switching to thread 1 (thread 1096.0xc40)]#0  0x7c90eb94 in 
>ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>#6  0x00000000 in ?? ()
>#0  0x7c90eb94 in ntdll!LdrAccessResource () from 
>#1  0x7c90e9ab in ntdll!ZwWaitForMultipleObjects () from 
>#2  0x7c8094e2 in KERNEL32!CreateFileMappingA () from 
>#3  0x00000002 in ?? ()
>#4  0x0021fe38 in ?? ()
>#5  0x00000001 in ?? ()
>#6  0x00000000 in ?? ()

Try "info threads" and you may see that thread 1 is what you're interested
in.  Windows creates a new thread in the attached process when gdb attaches
to it so this is not what you would normally be interested in.

Note that if the process is stopped in a Windows DLL the stack trace
will probably not be very informative.


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list