Looks like GDB in Cygwin does not catch Ctrl/C correctly

Looks like GDB in Cygwin does not catch Ctrl/C correctly

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

Hi All,

Another question for tonight:

So there's a program that basically enters a tight loop on some incorrect input (and needs to be debugged, obviously).

The program is otherwise rather basic, doesn't use anything outside K&R C RTL.

When I run the program under gdb, I want to interrupt it with Ctrl/C (as I would be doing
in Linux) and then step through the code to figure out where it is looping.

GDB does interrupt the program but when I do step or next, it looks like some
utility thread gets the actual control, and actually processes the INT signal, which then
terminates the program, making the debugging impossible:

Thread 1 "cprog" received signal SIGINT, Interrupt.
free_tree (tp=0x80004eae0) at cprog.c:1696
1696                    break;
(gdb) s
0x0000000180148990 in muto::release(_cygtls*) () from /usr/bin/cygwin1.dll
(gdb) s
Single stepping until exit from function _ZN4muto7releaseEP7_cygtls,
which has no line number information.
0x000000018013469b in _sigbe () from /usr/bin/cygwin1.dll
(gdb) s
Single stepping until exit from function _sigbe,
which has no line number information.
0x00000001801346e5 in sigdelayed () from /usr/bin/cygwin1.dll
(gdb) s
Single stepping until exit from function sigdelayed,
which has no line number information.
[Inferior 1 (process 6792) exited with code 01000]

Using "n" instead of "s"s gets the termination right away:

(gdb) n
[Inferior 1 (process 5020) exited with code 01000]

The program does have all the debugging info on (compiled with -g)
and can be stepped through successfully (in Cygwin too from the get go but not whe interrupted).

The same code compiled with the exact same gcc command, and run under gdb on Linux can be stepped through the actual
source code after having been interrupted with Ctrl/C.

Any ideas would be appreciated.

Thanks,
Anton

P.S. This is how the debugging session looks on Linux, for comparison, showing it does step through the actual code:

Program received signal SIGINT, Interrupt.
0x00000000004053f1 in implicit_gbl (value=0x6269f0) at cprog.c:2494
2494            switch(value->type)
(gdb) n
2527    }
(gdb) n
store_value (stack=0x7fffffffc718, tr=0x7fffffffc720, size=1, value=0x6269f0) at cprog.c:3805
3805            if(value->type == EX_LIT)
(gdb) n
3807                    store_word(stack->top, tr, size, value->data.lit);
(gdb)
...


--
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: Looks like GDB in Cygwin does not catch Ctrl/C correctly

[Takashi Yano]

On Tue, 21 Jan 2020 03:09:19 +0000
"Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin" <cygwin@cygwin.com> wrote:
> Hi All,
> 
> Another question for tonight:
> 
> So there's a program that basically enters a tight loop on some incorrect input (and needs to be debugged, obviously).
> 
> The program is otherwise rather basic, doesn't use anything outside K&R C RTL.
> 
> When I run the program under gdb, I want to interrupt it with Ctrl/C (as I would be doing
> in Linux) and then step through the code to figure out where it is looping.
> 
> GDB does interrupt the program but when I do step or next, it looks like some
> utility thread gets the actual control, and actually processes the INT signal, which then
> terminates the program, making the debugging impossible:
> 
> Thread 1 "cprog" received signal SIGINT, Interrupt.
> free_tree (tp=0x80004eae0) at cprog.c:1696
> 1696                    break;
> (gdb) s
> 0x0000000180148990 in muto::release(_cygtls*) () from /usr/bin/cygwin1.dll
> (gdb) s
> Single stepping until exit from function _ZN4muto7releaseEP7_cygtls,
> which has no line number information.
> 0x000000018013469b in _sigbe () from /usr/bin/cygwin1.dll
> (gdb) s
> Single stepping until exit from function _sigbe,
> which has no line number information.
> 0x00000001801346e5 in sigdelayed () from /usr/bin/cygwin1.dll
> (gdb) s
> Single stepping until exit from function sigdelayed,
> which has no line number information.
> [Inferior 1 (process 6792) exited with code 01000]
> 
> Using "n" instead of "s"s gets the termination right away:
> 
> (gdb) n
> [Inferior 1 (process 5020) exited with code 01000]
> 
> The program does have all the debugging info on (compiled with -g)
> and can be stepped through successfully (in Cygwin too from the get go but not whe interrupted).
> 
> The same code compiled with the exact same gcc command, and run under gdb on Linux can be stepped through the actual
> source code after having been interrupted with Ctrl/C.
> 
> Any ideas would be appreciated.
> 
> Thanks,
> Anton
> 
> P.S. This is how the debugging session looks on Linux, for comparison, showing it does step through the actual code:
> 
> Program received signal SIGINT, Interrupt.
> 0x00000000004053f1 in implicit_gbl (value=0x6269f0) at cprog.c:2494
> 2494            switch(value->type)
> (gdb) n
> 2527    }
> (gdb) n
> store_value (stack=0x7fffffffc718, tr=0x7fffffffc720, size=1, value=0x6269f0) at cprog.c:3805
> 3805            if(value->type == EX_LIT)
> (gdb) n
> 3807                    store_word(stack->top, tr, size, value->data.lit);
> (gdb)
> ...

What is your environment? Windows version, cygwin version and etc...

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Looks like GDB in Cygwin does not catch Ctrl/C correctly

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

> What is your environment? Windows version, cygwin version and etc...

$ uname -a
CYGWIN_NT-6.1 ANTON 3.1.0(0.340/5/3) 2019-12-01 05:20 x86_64 Cygwin

Windows 7 Home;  Cygwin 3.1.0

--
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: Looks like GDB in Cygwin does not catch Ctrl/C correctly

[Takashi Yano]

On Tue, 21 Jan 2020 03:29:47 +0000
"Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin"wrote:
> > What is your environment? Windows version, cygwin version and etc...
> $ uname -a
> CYGWIN_NT-6.1 ANTON 3.1.0(0.340/5/3) 2019-12-01 05:20 x86_64 Cygwin
> 
> Windows 7 Home;  Cygwin 3.1.0

This problem can be reproduced by:

gdb cat
run
press Ctrl-C
cont

In linux, cat continues to read, however, in cygwin it stops.
This also occurs under Cygwin 3.0.7, but does not occurs
in windows 10 1909 with Cygwin 3.1.2, i.e. when pseudo console
is enabled.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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