[Bug remote/18772] New: gdb does not respond to CTRL-C

[Bug remote/18772] New: gdb does not respond to CTRL-C

[moorel at ntlworld dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

            Bug ID: 18772
           Summary: gdb does not respond to CTRL-C
           Product: gdb
           Version: 7.9
            Status: NEW
          Severity: critical
          Priority: P2
         Component: remote
          Assignee: unassigned at sourceware dot org
          Reporter: moorel at ntlworld dot com
  Target Milestone: ---

Hi Support,

it looks like a bug has been introduced, somewhere between 7.5 & 7.9.
I do not have all the intermediate builds available to narrow this down.

I have a very simple testcase, running on Fedora Linux, but appears to be a
general issue I even reproduced on an ARM target.

1: #include <stdio.h>
2: int main() {
3:     int cond = 0;
4:     while(cond == 0) { /* do nothing  */ } // BREAK at this line
5:     return 0;
6: }

compile for debug
$ gcc -g -o app.exe app.c

run the application in gdbserver
$ gdbserver localhost:9999 app.exe

in gdb do the following
$ gdb app.exe
(gdb) target remote localhost:9999
(gdb) b app.c:4
(gdb) continue
(gdb) next

so now gdb is trying to run to the 'next' line, which it cannot reach because
the condition in the while loop is always true, so interrupt by sending CTRL-C
(gdb) ^C

nothing happens

The session is now locked up, if you issue another CTRL-C, the gdb client will
Quit
(gdb)^CQuit

The gdbserver is still running, but I have failed to interrupt

Try the same with gdb version 7.5 and it works

Thx
Lee

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[massimo.b at gmx dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

--- Comment #4 from Massimo B. <massimo.b at gmx dot net> ---
Any progress here? Is the proposed patch a reasonable solution and will be
integrated?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[paul at sourceware dot m.darkrain42.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Paul Aurich <paul at sourceware dot m.darkrain42.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul at sourceware dot m.darkrain4
                   |                            |2.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[rarul at rarul dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

rarul <rarul at rarul dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rarul at rarul dot com

--- Comment #5 from rarul <rarul at rarul dot com> ---
I don't think the proposed patch is good,
for it is wrong to send SIGINT to the pocess group.
See this ticket. Josh suggested the right approach.
https://sourceware.org/bugzilla/show_bug.cgi?id=18945

I'm not sure why this bug is not fixed yet.
In Yocto project case, they decided to apply the patch.
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-devtools/gdb/gdb/0011-gdbserver-ctrl-c-handling.patch
There're no active gdbserver maintainers?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[matic.kres at isystem dot si]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Matic Kres <matic.kres at isystem dot si> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matic.kres at isystem dot si

--- Comment #6 from Matic Kres <matic.kres at isystem dot si> ---
Agree with rarul, sending interrupt to group process is not a good choice.
My post about it:
https://sourceware.org/bugzilla/show_bug.cgi?id=26575

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aburgess at redhat dot com
         Resolution|---                         |WORKSFORME

--- Comment #7 from Andrew Burgess <aburgess at redhat dot com> ---
I tried to reproduce this issue with GDB 8.2 and 11.2 on x86-64 GNU/Linux using
Fedora 31, using the test program from the original comment.

I can't see any problems interrupting GDB using Ctrl-C.  I tested this using
'continue', 'next', and 'step' commands, and in all cases GDB interrupts as
expected (i.e. comes to a stop).

If any of the original bug reporters are still seeing this issue with a recent
version of GDB, then please do follow up and we can reopen this bug, but for no
I propose that we close this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[moorel at ntlworld dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Lee Moore <moorel at ntlworld dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |moorel at ntlworld dot com

--- Comment #8 from Lee Moore <moorel at ntlworld dot com> ---
wow I logged this 7 years ago!
I tried this with gdbserver/gdb 8.1, the problem no longer occurs

no idea at what point it got fixed

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[richsurgenor at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Rich Surgenor <richsurgenor at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richsurgenor at gmail dot com

--- Comment #9 from Rich Surgenor <richsurgenor at gmail dot com> ---
(In reply to Lee Moore from comment #8)
> wow I logged this 7 years ago!
> I tried this with gdbserver/gdb 8.1, the problem no longer occurs
> 
> no idea at what point it got fixed

This issue still happened to me on an ARMv7 target from a x86_64 host. Adding
the patch that sends kill to just the process when sending to the process group
fails worked instantly fixed the problem.

This is with gdbserver 10.2 and gdb 9.2

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[richsurgenor at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

--- Comment #10 from Rich Surgenor <richsurgenor at gmail dot com> ---
(In reply to Andrew Burgess from comment #7)
> I tried to reproduce this issue with GDB 8.2 and 11.2 on x86-64 GNU/Linux
> using Fedora 31, using the test program from the original comment.
> 
> I can't see any problems interrupting GDB using Ctrl-C.  I tested this using
> 'continue', 'next', and 'step' commands, and in all cases GDB interrupts as
> expected (i.e. comes to a stop).
> 
> If any of the original bug reporters are still seeing this issue with a
> recent version of GDB, then please do follow up and we can reopen this bug,
> but for no I propose that we close this issue.

Did you confirm that the pgid was != to the pid in your testing? In my case,
the pgid did not match the pgid or pid of any processes, resulting in the
signal not getting sent anywhere.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #11 from Andrew Burgess <aburgess at redhat dot com> ---
(In reply to Rich Surgenor from comment #10)

> Did you confirm that the pgid was != to the pid in your testing? In my case,
> the pgid did not match the pgid or pid of any processes, resulting in the
> signal not getting sent anywhere.

OK, that's pretty interesting.  So I guess you started debugging some process
that forks, you follow the fork, then you place the child into a different
process group?

Or am I overthinking this?

I'll try to craft a test that matches your description above later this week,
but any further hints you have about the nature of the failing situation would
be great.  

I'm reopening this issue for now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

--- Comment #12 from Andrew Burgess <aburgess at redhat dot com> ---
Created attachment 14082
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14082&action=edit
A reproducer for this issue

The attached file sig-c-bug.c is a reproducer for this issue.  The bug impacts
not just remote targets, but also native Linux targets too as of commit
2b718529b99.

Compile up the attached file as:

  gcc -g3 -O0 -Wall -Wextra -Werror  -o sig-c-bug.x sig-c-bug.c

Then run the test as:

  ./gdb/gdb --data-directory ./gdb/data-directory/ \
     ~/tmp/sig-c-bug.x \
     -q \
     -ex 'set detach-on-fork off' \
     -ex 'set follow-fork-mode parent' \
     -ex 'run' \
     -ex 'info inferiors' \
     -ex 'inferior 2' \
     -ex 'continue'

You should end up with inferior 2 running, every second you'll see a new line
of this output:

  Tick: 0
  Tick: 1
  Tick: 2
  Tick: 3
  Tick: 4
  ... and so on ...

try to interrupt gdb using ctrl-c ... it doesn't work for me.

Inferior 2 will automatically exit after 'Tick: 9', at which point you need to
restart the test.

The same behaviour can be seen when using a remote target, just start gdbserver
something like:

  gdbserver --multi :54321 sig-c-bug.x

and then:

  ./gdb/gdb --data-directory ./gdb/data-directory/ \
     ~/tmp/sig-c-bug.x \
     -q \
     -ex 'set sysroot /' \
     -ex 'set detach-on-fork off' \
     -ex 'set follow-fork-mode parent' \
     -ex 'target extended-remote :54321' \
     -ex 'continue' \
     -ex 'info inferiors' \
     -ex 'inferior 2' \
     -ex 'continue'

and the remote target will be ticking in inferior 2, and can't be interrupted.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[ghjghj530-bubu at yahoo dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

ghjghj530-bubu at yahoo dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ghjghj530-bubu at yahoo dot de

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[pedro at palves dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Pedro Alves <pedro at palves dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro at palves dot net

--- Comment #13 from Pedro Alves <pedro at palves dot net> ---
Once I'm done with my current priorities, my next project will be going back to
this:

 [PATCH v2 00/16] Interrupting programs that block/ignore SIGINT
 https://pi.simark.ca/gdb-patches/20210614212410.1612666-1-pedro@palves.net/

That redesigns how SIGINT is handled when native debugging, such that GDB
_always_ gets the SIGINT first instead of relying on the inferior getting it,
so I suspect it will fix Andrew's testcase when native debugging (though I
haven't tried it).  As for remote debugging with gdbserver, I will take a look
at it too, once I resume work on that series.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[dominik.b.czarnota+bugzilla at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Disconnect3d <dominik.b.czarnota+bugzilla at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominik.b.czarnota+bugzilla
                   |                            |@gmail.com

--- Comment #14 from Disconnect3d <dominik.b.czarnota+bugzilla at gmail dot com> ---
(In reply to Pedro Alves from comment #13)
> Once I'm done with my current priorities, my next project will be going back
> to this:
> 
>  [PATCH v2 00/16] Interrupting programs that block/ignore SIGINT
>  https://pi.simark.ca/gdb-patches/20210614212410.1612666-1-pedro@palves.net/
> 
> That redesigns how SIGINT is handled when native debugging, such that GDB
> _always_ gets the SIGINT first instead of relying on the inferior getting
> it, so I suspect it will fix Andrew's testcase when native debugging (though
> I haven't tried it).  As for remote debugging with gdbserver, I will take a
> look at it too, once I resume work on that series.

Hey,

Any progress on it?

I just stumbled on it when debugging an AARCH64 target [0] run via QEMU user
emulation [1]. I wonder if that it is a bug in the QEMU user emulation layer
here or if comes from GDB?

[0]
https://github.com/perfectblue/ctf-writeups/tree/master/2019/insomnihack-teaser-2019/nyanc/challenge
[1] Via command `qemu-aarch64 -g 1234 ./nyanc`, but I first used patchelf to
set interpreter and libc:
```
patchelf --set-interpreter ./ld-linux-aarch64.so.1 ./nyanc 
patchelf --replace-needed libc.so.6 ./libc.so.6 ./nyanc 
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[filip.bascarevic at siemens dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Filip Bascarevic <filip.bascarevic at siemens dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |filip.bascarevic at siemens dot co
                   |                            |m

--- Comment #15 from Filip Bascarevic <filip.bascarevic at siemens dot com> ---
(In reply to Pedro Alves from comment #13)
> Once I'm done with my current priorities, my next project will be going back
> to this:
> 
>  [PATCH v2 00/16] Interrupting programs that block/ignore SIGINT
>  https://pi.simark.ca/gdb-patches/20210614212410.1612666-1-pedro@palves.net/
> 
> That redesigns how SIGINT is handled when native debugging, such that GDB
> _always_ gets the SIGINT first instead of relying on the inferior getting
> it, so I suspect it will fix Andrew's testcase when native debugging (though
> I haven't tried it).  As for remote debugging with gdbserver, I will take a
> look at it too, once I resume work on that series.

Hello community,

it seems this patch also broke Eclipse Suspend functionality during debugging.
I think the Eclipse also sends CTRL-C when the user presses Suspend button. I
noticed it from the GDB release 11.1 (10.2 works). 
Used remote debugging of the Qemu target Aarch64 with Eclipse in Windows. 
Feel free to contact me for any support or additional information

Best regards, 
Filip Bascarevic

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

--- Comment #16 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4c35c4c6a779c79e456b7a5311f74aafc9026bd5

commit 4c35c4c6a779c79e456b7a5311f74aafc9026bd5
Author: Tom de Vries <tdevries@suse.de>
Date:   Sun Nov 27 10:31:50 2022 +0100

    [gdb/server] Emit warning for SIGINT failure

    Consider the executable from test-case gdb.base/interrupt-daemon.exp.

    When starting it using gdbserver:
    ...
    $ ./build/gdbserver/gdbserver localhost:2345 \
      ./outputs/gdb.base/interrupt-daemon/interrupt-daemon
    ...
    and connecting to it using gdb:
    ...
    $ gdb -q -ex "target remote localhost:2345" \
        -ex "set follow-fork-mode child" \
        -ex "break daemon_main" -ex cont
    ...
    we are setup to do the same as in the test-case: interrupt a running
inferior
    using ^C.

    So let's try:
    ...
    (gdb) continue
    Continuing.
    ^C
    ...
    After pressing ^C, nothing happens.  This a known problem, filed as
    PR remote/18772.

    The problem is that in linux_process_target::request_interrupt, a kill is
used
    to send a SIGINT, but it fails.  And it fails silently.

    Make the failure verbose by adding a warning, such that the gdbserver
output
    becomes more helpful:
    ...
    Process interrupt-daemon created; pid = 15068
    Listening on port 2345
    Remote debugging from host ::1, port 35148
    Detaching from process 15068
    Detaching from process 15085
    gdbserver: Sending SIGINT to process group of pid 15068 failed: \
      No such process
    ...

    Note that the failure can easily be reproduced using the test-case and
target
    board native-gdbserver:
    ...
    (gdb) continue^M
    Continuing.^M
    PASS: gdb.base/interrupt-daemon.exp: fg: continue
    ^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout)
    ...
    as reported in PR server/23382.

    Tested on x86_64-linux.
    Approved-By: Simon Marchi <simon.marchi@efficios.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[eldar.abusalimov at jetbrains dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Eldar Abusalimov <eldar.abusalimov at jetbrains dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eldar.abusalimov@jetbrains.
                   |                            |com

--- Comment #17 from Eldar Abusalimov <eldar.abusalimov at jetbrains dot com> ---
There's one more thing why the naive `kill (-signal_pid, SIGINT);` is wrong.

In case the target PID is 1, it calls `kill` passing -1 to it, which has a
special meaning (quoting
https://man7.org/linux/man-pages/man2/kill.2.html#DESCRIPTION):

       If pid equals -1, then sig is sent to every process for which the
       calling process has permission to send signals, except for
       process 1 (init), but see below.

That is, it attempts to interrupt any process other than the one it is supposed
to!

Debugging PID 1 may sound an edge case, but it is actually perfectly fine to do
so in case of a sole process running inside a Docker container. In other words,
it's not necessarily even the init process, like systemd or upstart, it's often
a legit regular program that you develop yourself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug remote/18772] gdb does not respond to CTRL-C

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18772

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #18 from Tom Tromey <tromey at sourceware dot org> ---
On Linux at least we could use PTRACE_INTERRUPT, see bug #15250.

-- 
You are receiving this mail because:
You are on the CC list for the bug.