X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: "Hans Horn" <hannes AT 2horns DOT com>
Subject:  Re: gdb attach to process to produce stacktrace
Date:  Wed, 20 Sep 2006 08:06:11 -0700
Lines: 52
Message-ID: <eerlgl$fnq$1@sea.gmane.org>
References:  <eeri1a$1qb$1 AT sea DOT gmane DOT org> <20060920144836 DOT GA23721 AT trixie DOT casa DOT cgf DOT cx>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Exactly, thread 1 is of interest. That's the reason why the code posted 
switches to thread 1!

The real question is as to why the parent process needs to go into a 
while(1) loop in order to produce the desired trace.

H.
"Christopher Faylor" <cgf-no-personal-reply-please AT cygwin DOT com> wrote in 
message news:20060920144836 DOT GA23721 AT trixie DOT casa DOT cgf DOT cx...
> 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.
>>http://thread.gmane.org/gmane.os.cygwin/58420/focus=58420) 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
>>/cygdrive/c/WINDOWS/system32/ntdll.dll
>>  3 thread 1096.0xce0  0x7c90eb94 in ntdll!LdrAccessResource () from
>>/cygdrive/c/WINDOWS/system32/ntdll.dll
>>  2 thread 1096.0x8ec  0x7c90eb94 in ntdll!LdrAccessResource () from
>>/cygdrive/c/WINDOWS/system32/ntdll.dll
>>  1 thread 1096.0xc40  0x7c90eb94 in ntdll!LdrAccessResource () from
>>/cygdrive/c/WINDOWS/system32/ntdll.dll
>>[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
>>/cygdrive/c/WINDOWS/system32/ntdll.dll
>>#1  0x7c90e9ab in ntdll!ZwWaitForMultipleObjects () from
>>/cygdrive/c/WINDOWS/system32/ntdll.dll
>>#2  0x7c8094e2 in KERNEL32!CreateFileMappingA () from
>>/cygdrive/c/WINDOWS/system32/kernel32.dll
>>#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.
>
> cgf
> 




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/