Re: Debugging totally broken with latest everything?

2013-04-15 Thread Christopher Faylor
On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote:
>  Some notes on the above:
>
>  The same happens with both the previous version and current snapshot of the
>cygwin dll.  It also happens with both current gdb and an old gdb
>6.8.0.20080328-cvs that I have lying around.
>
>  The hw.exe in question is your bog-standard hello world, compiled with "-g
>-O0" using gcc4-4.5.3-3.
>
>  "kill -9" won't kill gdb; I have to use Windows task manager.  If I've
>attached gdb to the hung gdb, I can kill it from there using the "k" 
>instruction.
>
>  Anyone else having similar problems?

You're probably seeing a known bug in gdb where it no longer works well
when run from a console window.  There is a race where gdb tries to get
tty information from a stopped cygwin process.  Although I didn't
introduce the problem, I have tried to fix it from time to time without
much luck.

Debugging from mintty will probably work better.

cgf

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



Re: Debugging totally broken with latest everything?

2013-04-15 Thread Dave Korn
On 15/04/2013 18:14, Christopher Faylor wrote:
> On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote:
>>  Some notes on the above:
>>
>>  The same happens with both the previous version and current snapshot of the
>> cygwin dll.  It also happens with both current gdb and an old gdb
>> 6.8.0.20080328-cvs that I have lying around.
>>
>>  The hw.exe in question is your bog-standard hello world, compiled with "-g
>> -O0" using gcc4-4.5.3-3.
>>
>>  "kill -9" won't kill gdb; I have to use Windows task manager.  If I've
>> attached gdb to the hung gdb, I can kill it from there using the "k" 
>> instruction.
>>
>>  Anyone else having similar problems?
> 
> You're probably seeing a known bug in gdb where it no longer works well
> when run from a console window.  There is a race where gdb tries to get
> tty information from a stopped cygwin process.  Although I didn't
> introduce the problem, I have tried to fix it from time to time without
> much luck.

  It must be an interaction between gdb and the cygwin dll, since my
old-and-previously-working-just-fine-in-a-console gdb-6 has also stopped 
working.

> Debugging from mintty will probably work better.

  It certainly does.  Thanks for the tip.

cheers,
  DaveK


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



Re: Debugging totally broken with latest everything?

2013-04-15 Thread Ryan Johnson

On 15/04/2013 1:14 PM, Christopher Faylor wrote:

On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote:

  Some notes on the above:

  The same happens with both the previous version and current snapshot of the
cygwin dll.  It also happens with both current gdb and an old gdb
6.8.0.20080328-cvs that I have lying around.

  The hw.exe in question is your bog-standard hello world, compiled with "-g
-O0" using gcc4-4.5.3-3.

  "kill -9" won't kill gdb; I have to use Windows task manager.  If I've
attached gdb to the hung gdb, I can kill it from there using the "k" 
instruction.

  Anyone else having similar problems?

You're probably seeing a known bug in gdb where it no longer works well
when run from a console window.  There is a race where gdb tries to get
tty information from a stopped cygwin process.  Although I didn't
introduce the problem, I have tried to fix it from time to time without
much luck.
I've also seen the problem, my workaround so far has been to ensure the 
process is running again before attaching gdb to it (assuming you 
stopped it with ^Z so that jobs -p could report its pid). Not that I 
actually remember to do this most of the time...



Debugging from mintty will probably work better.
That's a rather unfortunate interaction with the long-standing "feature" 
that interrupting programs with ^C only works if gdb runs in a console 
window (STC I used today is below in case I've gotten something wrong).


Am I missing some obvious workaround?

Ryan

STC: when compiling and running this:

#include 
#include 
int main() {
printf("pid: %d\n", getpid());
sleep(10);
}

... ^C does not break in (it exits normally) when gdb runs inside 
mintty; putting in a cmd.exe window allows ^C to break in with SIGTRAP 
(though the stack trace is utterly useless since the thread is in 
windows land at that point).




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



Re: Debugging totally broken with latest everything?

2013-04-15 Thread jojelino

On 2013-04-16 AM 1:03, Dave Korn wrote:

Thread 2 (Thread 5536.0xe2c):
#0  0x77f88a87 in ntdll!ZwReadFile () from /win/c/WINNT/system32/ntdll.dll
#1  0x7c586381 in ?? ()
#2  0x610dd075 in wait_sig ()
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/sigproc.cc:1360
#3  0x61003e65 in cygthread::callfunc (this=0x6118a400 ,
 issimplestub=)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygthread.cc:51
#4  0x610043ef in cygthread::stub (arg=0x6118a400 )
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygthread.cc:93
#5  0x6100533d in _cygtls::call2 (this=,
 func=0x610043a0 , arg=0x6118a400 ,
 buf=0x610054cb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygtls.cc:99
#6  0x0270ffb4 in ?? ()
#7  0x7c57b3bc in ?? ()
#8  0x in ?? ()

Thread 1 (Thread 5536.0x1640):
#0  0x77f88f43 in ntdll!ZwWriteFile () from /win/c/WINNT/system32/ntdll.dll
#1  0x7c5864f9 in ?? ()
#2  0x610dc3f4 in sig_send (p=0x14ea444, si=..., tls=0x0)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/sigproc.cc:736
#3  0x6106b028 in tty_min::kill_pgrp (this=0x60fc, sig=-43)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/fhandler_termios.cc:133
#4  0x6106b129 in fhandler_termios::tcsetpgrp (
 this=0x61274690 <__real__Znwj+1629963920>, pgid=2428)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/fhandler_termios.cc:85
#5  0x610f9f78 in tcsetpgrp (fd=0, pgid=2428)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/termios.cc:237
#6  0x610d6745 in _sigfe () from /usr/bin/cygwin1.dll
#7  0x200bbb70 in ?? ()
#8  0x00418662 in ?? ()
#9  0x00521908 in ?? ()
#10 0x004eb052 in ?? ()
---Type  to continue, or q  to quit---
#11 0x004eb265 in ?? ()
#12 0x004dd4a0 in ?? ()
#13 0x004dd6a5 in ?? ()
#14 0x005b11ab in ?? ()
#15 0x004feccb in ?? ()
#16 0x004ff6c0 in ?? ()
#17 0x005f2de2 in ?? ()
#18 0x004fed3b in ?? ()
#19 0x004fd9a0 in ?? ()
#20 0x004fdfc4 in ?? ()
#21 0x004fe4b8 in ?? ()
#22 0x004fe537 in ?? ()
#23 0x004f8345 in ?? ()
#24 0x004f6e0a in ?? ()
#25 0x004f8a85 in ?? ()
#26 0x004f6e0a in ?? ()
#27 0x004f9632 in ?? ()
#28 0x004011a8 in ?? ()
#29 0x6100763a in _cygwin_exit_return ()
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/dcrt0.cc:974
#30 0x6100533d in _cygtls::call2 (this=,
 func=0x61006c50 , arg=0x0,
 buf=0x610054cb <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>)
 at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygtls.cc:99
#31 0x014eff78 in ?? ()
#32 0x006c1df2 in ?? ()
#33 0x00401015 in ?? ()
#34 0x7c5989d5 in ?? ()
#35 0x in ?? ()
(gdb)


   Some notes on the above:

   The same happens with both the previous version and current snapshot of the
cygwin dll.  It also happens with both current gdb and an old gdb
6.8.0.20080328-cvs that I have lying around.

   The hw.exe in question is your bog-standard hello world, compiled with "-g
-O0" using gcc4-4.5.3-3.

   "kill -9" won't kill gdb; I have to use Windows task manager.  If I've
attached gdb to the hung gdb, I can kill it from there using the "k" 
instruction.

   Anyone else having similar problems?

 cheers,
   DaveK



As far as i know, wait_sig thread in debugee is interrupted after 
stepping or breakpoint( n s si ni ). so, if you don't give cygwin 
sufficient time during gdb session until wait_sig thread handles signal 
about terminal, it hangs like you observed.


--
Regards.


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