Re: gdb attach to process to produce stacktrace

2006-09-20 Thread Christopher Layne
On Wed, Sep 20, 2006 at 03:17:29PM -0400, Ethan Tira-Thompson wrote: > For a quick example, try figuring out why this example program is > crashing... The idea is simple: set up an array of strings containing > 'a' through 'z', build a string from 100 random selections, and then > display the

Re: gdb attach to process to produce stacktrace

2006-09-20 Thread Christopher Faylor
On Wed, Sep 20, 2006 at 03:17:29PM -0400, Ethan Tira-Thompson wrote: >Wait, wait, don't give up so quickly -- this is the same problem I >reported a while back as well, and I'd like to see a better >resolution than "doctor, it hurts when I move my arm"; "well then >don't move your arm!" ...so

Re: gdb attach to process to produce stacktrace

2006-09-20 Thread Ethan Tira-Thompson
Wait, wait, don't give up so quickly -- this is the same problem I reported a while back as well, and I'd like to see a better resolution than "doctor, it hurts when I move my arm"; "well then don't move your arm!" ...some of us actually need to use our arms. Maybe you can get around using

Re: gdb attach to process to produce stacktrace

2006-09-20 Thread Hans Horn
That's all I needed to know. So in order for the process I'm attaching gdb to to terminate on its own I must not use anything that ends up in a windows dll. In the mingw/msys sources (msys\rt\src\newlib\libc\sys\go32\sleep.c) I found a sleep impl (DJ Delorie, 1991) that emulates the sleep functi

Re: gdb attach to process to produce stacktrace

2006-09-20 Thread Christopher Faylor
On Wed, Sep 20, 2006 at 08:06:11AM -0700, Hans Horn wrote: >Exactly, thread 1 is of interest. That's the reason why the code posted >switches to thread 1! I apologize for missing that but I did tell you that the stack trace would not be useful if the program was stopped in a Windows DLL, which it

RE: gdb attach to process to produce stacktrace

2006-09-20 Thread Dave Korn
On 20 September 2006 16:06, Hans Horn wrote: > 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. Because then you're running in the program code, whereas in the sleep function you've ended up in a windows dll function and

Re: gdb attach to process to produce stacktrace

2006-09-20 Thread Hans Horn
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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTE

Re: gdb attach to process to produce stacktrace

2006-09-20 Thread Christopher Faylor
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

gdb attach to process to produce stacktrace

2006-09-20 Thread Hans Horn
Group, 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] *