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