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

Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin cygwin@cygwin.com
Tue Jan 21 03:09:00 GMT 2020

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.


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

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

More information about the Cygwin mailing list