Mail Archives: cygwin/2003/12/28/10:16:40
On Sun, 28 Dec 2003, Igor Pechtchanski wrote:
> On Sun, 28 Dec 2003, Frédéric L. W. Meunier wrote:
>
> > On Sat, 27 Dec 2003, Christopher Faylor wrote:
> >
> > > On Sat, Dec 27, 2003 at 07:42:18PM -0200, Frédéric L. W. Meunier wrote:
> > > >I did the following:
> > > >
> > > >Start the application in a terminal.
> > > >Use ps in another terminal.
> > > >Use gdb -p from that terminal.
> > > >
> > > >Then:
> > > >
> > > >(gdb) c
> > > >Continuing.
> > > >
> > > >Do something with the application.
> > > >
> > > >Then I tried ^C in gdb and it didn't work, but it works on
> > > >Linux.
> > > >
> > > >Sorry, I'm not used to debug things, but I'd like to know why
> > > >the above doesn't work.
> > > >
> > > >I'm trying to investigate the ELinks problem with compressed
> > > >files, but it turns out to be a PITA. I can't reproduce it on
> > > >Linux, but I guess it'd have worked since ^C does.
> > >
> > > Type ^C on the console that is running ELinks.
> >
> > Thanks, I at least got back the gdb prompt, but it always
> > returns the same things with a bt, also with other
> > applications:
> >
> > (gdb) c
> > Continuing.
> >
> > Program received signal SIGINT, Interrupt.
> > [Switching to thread 1452.0x788]
> > 0x77ea31c7 in KERNEL32!GetAtomNameA () from /c/WINDOWS/system32/kernel32.dll
> > (gdb) bt
> > #0 0x77ea31c7 in KERNEL32!GetAtomNameA ()
> > from /c/WINDOWS/system32/kernel32.dll
> > #1 0x77f57d70 in ntdll!RtlAppendStringToString ()
> > from /c/WINDOWS/System32/ntdll.dll
> > #2 0x77f58a3a in ntdll!RtlAppendStringToString ()
> > from /c/WINDOWS/System32/ntdll.dll
> >
> > I compiled ELinks with --enable-debug, which adds -g. Doing the
> > same on Linux (c, bt, ^C) always returns lines from the ELinks
> > sources.
> >
> > Well, I uploaded a new trace in case it helps -
> > http://www.pervalidus.net/tmp/elinks.txt.gz. It's much smaller.
> > I used the latest cygwin1.dll and strace snapshots, strace -p
> > -t, and only started it at the time I connected to the URL.
>
> This may be way off-topic (this list is not intended to provide gdb help),
> but it looks like a lot of debugging with Cygwin goes beyond rudimentary
> gdb capabilities, since, AFAIU, *any* Cygwin program is multi-threaded (in
> the Windows sense). For more information on the gdb thread commands,
> visit "info -f gdb.info-12 -n 'GDB/MI Thread Commands'". A short summary
> is below.
>
> To get the list of threads, use the 'info threads' gdb command, and then
> use 'thread NUM' to switch to thread number NUM. Once you're in the right
> thread, you can get a meaningful backtrace.
I had tried that, but after using ^C in the application it
always returns the same information for all threads. I think
I've given up.
--
How to contact me - http://www.pervalidus.net/contact.html
--
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/
- Raw text -