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/
