[1/1,V5] gdb : Signal to pstack/gdb kills the attached process.

Message ID 1715252036-11931-1-git-send-email-partha.satapathy@oracle.com
State New
Headers
Series [1/1,V5] gdb : Signal to pstack/gdb kills the attached process. |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 success Testing passed

Commit Message

Partha Satapathy May 9, 2024, 10:53 a.m. UTC
  From: Partha Sarathi Satapathy <partha.satapathy@oracle.com>

Problem: While gdb is attaching an inferior, if ctrl-c is pressed in the
middle of the process attach,  the sigint is passed to the debugged
process. This triggers the exit of the inferior. For example in pstack,
printing a stack can take significant time, and ctrl-c is pressed to
abort the pstack/gdb application. This in turn kills the debugged
process, which can be critical for the system. In this case, the
intention of ctrl+c is to kill pstack/gdb, but not the inferior
application.
gdb -p <<pid>>
or gdb /proc/<<pid>>/exe pid
Attaching to process
<< ctrl+c is pressed during attach
(gdb) q
<<<< inferior process exited >>>>

A Ctrl-C/sigint received by gdb during the attachment of an inferior
passed to the debugged at some definite points during the window of
process attachment. The process of attaching an inferior is a multistep
process, and it takes time to get ready with the GDB prompt. As the
debugger and debugger are not fully attached during this period, the
sigint takes its default action to terminate the process.

Solution: While GDB attaches processes, the inferior is not the current
session leader. Hence, until attach is complete and the GDB prompt is
available, the sigint should not be passed to the inferior.
The signal should be skipped if the process runs in the background. With
this approach, we can skip passing the signature if the process is
attached to the GDB and the process attach is not complete.

attach_flag : Set if process is attached
sync_flag   : Set if attach is complete
If attached and sync_flag is not set, dont kill attached process
---
 gdb/infcmd.c   | 2 ++
 gdb/inferior.h | 3 +++
 gdb/inflow.c   | 2 ++
 3 files changed, 7 insertions(+)
  

Comments

Tom Tromey May 9, 2024, 2:32 p.m. UTC | #1
>>>>> "Partha" == Partha Satapathy <partha.satapathy@oracle.com> writes:

IMO it would be best if Pedro reviewed this, but...

Partha> diff --git a/gdb/inflow.c b/gdb/inflow.c
Partha> index 773ac0ba4997..381e6e4c22dd 100644
Partha> --- a/gdb/inflow.c
Partha> +++ b/gdb/inflow.c
Partha> @@ -585,6 +585,8 @@ child_pass_ctrlc (struct target_ops *self)
Partha>        if (inf->terminal_state != target_terminal_state::is_ours)
Partha>  	{
Partha>  	  gdb_assert (inf->pid != 0);
Partha> +	  if ((inf->attach_flag) && !(inf->sync_flag))
Partha> +	    return;

... if this code is run, doesn't it mean a C-c will be ignored?

Also earlier:

Partha> +  check_quit_flag();

I think this just returns true/false and clears the flag.
That doesn't seem right.

Maybe check_quit_flag should be marked [[nodiscard]].

Tom
  
Pedro Alves May 10, 2024, 8:19 p.m. UTC | #2
Hi.

Just wanted to let you know that I've read all the discussion around this until this
email I'm replying to, and started thinking about it a bit.  Unfortunately this is one of
those areas in GDB where the right change is rarely immediately obvious (to me).

Some questions:

 - If you ctrl-c to abort the attach, do we really abort the 
   attach properly?  Or do we stay attached in some half broken state?

 - Below you mention pstack, where can we find it?  And you mention
   that ctrl-c is pressed while that is printing a stack.  I'm assuming
   that's a backtrace command.  I'm confused in that case, as if that is
   so, then we should already be past the initial attach.  The question
   would then becomes, shouldn't gdb have the terminal at that point?
   How come it does not?

I'm wondering whether Baris's patch to eliminate the inferior
continuations would help with this, as it probably makes the attaching
sequence synchronous.  I should probably look at that one.

Pedro Alves
  
Pedro Alves May 13, 2024, 2:49 p.m. UTC | #3
Adding another question to the list below.  (I haven't tried to reproduce this yet myself, btw.)

On 2024-05-10 21:19, Pedro Alves wrote:
> Hi.
> 
> Just wanted to let you know that I've read all the discussion around this until this
> email I'm replying to, and started thinking about it a bit.  Unfortunately this is one of
> those areas in GDB where the right change is rarely immediately obvious (to me).
> 
> Some questions:
> 
>  - If you ctrl-c to abort the attach, do we really abort the 
>    attach properly?  Or do we stay attached in some half broken state?
> 
>  - Below you mention pstack, where can we find it?  And you mention
>    that ctrl-c is pressed while that is printing a stack.  I'm assuming
>    that's a backtrace command.  I'm confused in that case, as if that is
>    so, then we should already be past the initial attach.  The question
>    would then becomes, shouldn't gdb have the terminal at that point?
>    How come it does not?

#3 - The patch description states:

 > Problem: While gdb is attaching an inferior, if ctrl-c is pressed in the
 > middle of the process attach,  the sigint is passed to the debugged
 > process.  This triggers the exit of the inferior.

This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does that manage
to trigger the exit of the inferior at all?  ptrace should intercept the
SIGINT before the inferior ever sees it.  Did it not?

Or could it be that the real issue is that because that sends the SIGINT
to all the processes in the inferior's pgrp, we kill more processes than
the one we're attaching to, and those processes exiting cause the inferior
to exit as well.  If so, then this is orthogonal to the initial attach,
and can happen after the attach as well.  There is a bug open about this
on bugzilla.

Pedro Alves

> 
> I'm wondering whether Baris's patch to eliminate the inferior
> continuations would help with this, as it probably makes the attaching
> sequence synchronous.  I should probably look at that one.
> 
> Pedro Alves
>
  
Partha Satapathy May 16, 2024, 7:15 a.m. UTC | #4
On 5/13/2024 8:19 PM, Pedro Alves wrote:
> Adding another question to the list below.  (I haven't tried to reproduce this yet myself, btw.)
> 
> On 2024-05-10 21:19, Pedro Alves wrote:
>> Hi.
>>
>> Just wanted to let you know that I've read all the discussion around this until this
>> email I'm replying to, and started thinking about it a bit.  Unfortunately this is one of
>> those areas in GDB where the right change is rarely immediately obvious (to me).
>>
>> Some questions:
>>
>>   - If you ctrl-c to abort the attach, do we really abort the
>>     attach properly?  Or do we stay attached in some half broken state?
>>
>>   - Below you mention pstack, where can we find it?  And you mention
>>     that ctrl-c is pressed while that is printing a stack.  I'm assuming
>>     that's a backtrace command.  I'm confused in that case, as if that is
>>     so, then we should already be past the initial attach.  The question
>>     would then becomes, shouldn't gdb have the terminal at that point?
>>     How come it does not?
> 
> #3 - The patch description states:
> 
>   > Problem: While gdb is attaching an inferior, if ctrl-c is pressed in the
>   > middle of the process attach,  the sigint is passed to the debugged
>   > process.  This triggers the exit of the inferior.
> 
> This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does that manage
> to trigger the exit of the inferior at all?  ptrace should intercept the
> SIGINT before the inferior ever sees it.  Did it not?
> 
> Or could it be that the real issue is that because that sends the SIGINT
> to all the processes in the inferior's pgrp, we kill more processes than
> the one we're attaching to, and those processes exiting cause the inferior
> to exit as well.  If so, then this is orthogonal to the initial attach,
> and can happen after the attach as well.  There is a bug open about this
> on bugzilla.
> 
> Pedro Alves
> 
>>
>> I'm wondering whether Baris's patch to eliminate the inferior
>> continuations would help with this, as it probably makes the attaching
>> sequence synchronous.  I should probably look at that one.
>>
>> Pedro Alves
>>


Thanks Pedro and Tom for reviewing the problem.


Problem :
pstack,  dumps the stack of all threads in a process. In some cases 
printing of stack can take significant time and ctrl-c is pressed to 
abort pstack/gdb application. This in turn kills the debugged process, 
which can be  critical for the system. In this case the intention of 
“ctrl+c” to kill pstack/gdb, but not the target application.


# tail pstack -n 12

# Run GDB, strip out unwanted noise.
# --readnever is no longer used since .gdb_index is now in use.
$GDB --quiet -nx $GDBARGS /proc/$1/exe $1 <<EOF 2>&1 |
set width 0
set height 0
set pagination no
$backtrace
EOF
/bin/sed -n \
     -e 's/^\((gdb) \)*//' \
     -e '/^#/p' \
     -e '/^Thread/p'


This is the interest part in the pstack, rest is cosmetic.

pstack uses:
# pstack 1

#0  0x00007fa18cf44017 in epoll_wait () from /lib64/libc.so.6
#1  0x00007fa18e67e036 in sd_event_wait () from 
/usr/lib/systemd/libsystemd-shared-239.so
#2  0x00007fa18e67f33b in sd_event_run () from 
/usr/lib/systemd/libsystemd-shared-239.so
#3  0x000055c155da8c22 in manager_loop ()
#4  0x000055c155d5f133 in main ()

Reproduction:

The debugged application generally attached to process by:
gdb -p <<pid>>
or gdb /proc/<<pid>>/exe pid
pstack uses the latter  method to attach the debugged to gdb. If the
application is large or process of reading symbols is slow, gives a good
window to press the ctrl+c during attach. Spawning "gdb" under "strace
-k" makes gdb a lot slower and gives a larger window to easily press the
ctrl+c at the precise period i.e. during the attach of the debugged
process. The above strace hack will enhance rate of reproduction of the
issue. Testcase:

With GDB 13.1
ps aux | grep abrtd
root     2195168   /usr/sbin/abrtd -d -s

#strace -k -o log gdb -p 2195168
Attaching to process 2195168
[New LWP 2195177]
[New LWP 2195179]
^C[Thread debugging using libthread_db enabled]
<<<<   Note the ctrl+c is pressed after attach is initiated and it’s
still reading the symbols from library >>>> Using host libthread_db
library "/lib64/libthread_db.so.1".
0x00007fe3ed6d70d1 in poll () from /lib64/libc.so.6
(gdb) q
A debugging session is active.
            Inferior 1 [process 2195168] will be detached Quit anyway? (y
or n) y Detaching from program: /usr/sbin/abrtd, process 2195168

# ps aux | grep 2195168
<<<< Process exited >>>>

This is having a very narrow window to press the ctrlc.
Session1 :

]$ ps aux | grep abrtd
root        1329  0.0  0.0 602624 13076 ?        Ssl  May03   0:00 
/usr/sbin/abrtd -d -s

Session2:

# ./tpstack 1329

+ strace -o omlog -k ./gdb --quiet -nx -ex 'set width 0' -ex 'set height 
0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all 
bt' -ex quit /proc/1329/exe 1329
Reading symbols from /proc/1329/exe...
Python Exception <class 'AttributeError'>: module 'gdb' has no attribute 
'_handle_missing_debuginfo'
Reading symbols from .gnu_debugdata for /usr/sbin/abrtd...
(No debugging symbols found in .gnu_debugdata for /usr/sbin/abrtd)
Attaching to program: /proc/1329/exe, process 1329
[New LWP 1399]
[New LWP 1349] ^C

Session1:
[opc@pssatapa-ol8 TEST]$ ps aux | grep abrtd
<<<1329 Is killed >>>

This is a very small window, so a heavy application is good for 
reproduction. I modified the the last part of pstack like:
# Run GDB, strip out unwanted noise.
# --readnever is no longer used since .gdb_index is now in use.
strace -o omlog -k  ./gdb  --quiet -nx  -ex 'set width 0' -ex 'set 
height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread 
apply all bt' -ex quit  /proc/$1/exe $1

The strace with -k on gdb make gdb slow and we get a window to press 
Ctrl+c.  otherwise the window is very small to time the signal. We 
observe the problem while the FileStsyem or Kernel or proc FS is slow.

The signal is not intended to the inferior.
The signal is passed from "gdb" to the inferior.

The SIGINT handler in gdb, marks the QUIT flag and
in some paths we check the quit flag and pass the signal to inferior.
That is killing the inferior.

On :
+  check_quit_flag();
This should be set only when inf->attach_flag is true.
I will add the check in next iteration.
The idea here is to clear any pending QUIT flag set by sigint
else, post we set the sync_flag , a check to QUIT Flag
and can kill the inferior.

Thanks
Partha
  
Partha Satapathy June 3, 2024, 5:21 a.m. UTC | #5
On 5/16/2024 12:45 PM, Partha Satapathy wrote:
> On 5/13/2024 8:19 PM, Pedro Alves wrote:
>> Adding another question to the list below.  (I haven't tried to 
>> reproduce this yet myself, btw.)
>>
>> On 2024-05-10 21:19, Pedro Alves wrote:
>>> Hi.
>>>
>>> Just wanted to let you know that I've read all the discussion around 
>>> this until this
>>> email I'm replying to, and started thinking about it a bit.  
>>> Unfortunately this is one of
>>> those areas in GDB where the right change is rarely immediately 
>>> obvious (to me).
>>>
>>> Some questions:
>>>
>>>   - If you ctrl-c to abort the attach, do we really abort the
>>>     attach properly?  Or do we stay attached in some half broken state?
>>>
>>>   - Below you mention pstack, where can we find it?  And you mention
>>>     that ctrl-c is pressed while that is printing a stack.  I'm assuming
>>>     that's a backtrace command.  I'm confused in that case, as if 
>>> that is
>>>     so, then we should already be past the initial attach.  The question
>>>     would then becomes, shouldn't gdb have the terminal at that point?
>>>     How come it does not?
>>
>> #3 - The patch description states:
>>
>>   > Problem: While gdb is attaching an inferior, if ctrl-c is pressed 
>> in the
>>   > middle of the process attach,  the sigint is passed to the debugged
>>   > process.  This triggers the exit of the inferior.
>>
>> This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does that 
>> manage
>> to trigger the exit of the inferior at all?  ptrace should intercept the
>> SIGINT before the inferior ever sees it.  Did it not?
>>
>> Or could it be that the real issue is that because that sends the SIGINT
>> to all the processes in the inferior's pgrp, we kill more processes than
>> the one we're attaching to, and those processes exiting cause the 
>> inferior
>> to exit as well.  If so, then this is orthogonal to the initial attach,
>> and can happen after the attach as well.  There is a bug open about this
>> on bugzilla.
>>
>> Pedro Alves
>>
>>>
>>> I'm wondering whether Baris's patch to eliminate the inferior
>>> continuations would help with this, as it probably makes the attaching
>>> sequence synchronous.  I should probably look at that one.
>>>
>>> Pedro Alves
>>>
> 
> 
> Thanks Pedro and Tom for reviewing the problem.
> 
> 
> Problem :
> pstack,  dumps the stack of all threads in a process. In some cases 
> printing of stack can take significant time and ctrl-c is pressed to 
> abort pstack/gdb application. This in turn kills the debugged process, 
> which can be  critical for the system. In this case the intention of 
> “ctrl+c” to kill pstack/gdb, but not the target application.
> 
> 
> # tail pstack -n 12
> 
> # Run GDB, strip out unwanted noise.
> # --readnever is no longer used since .gdb_index is now in use.
> $GDB --quiet -nx $GDBARGS /proc/$1/exe $1 <<EOF 2>&1 |
> set width 0
> set height 0
> set pagination no
> $backtrace
> EOF
> /bin/sed -n \
>      -e 's/^\((gdb) \)*//' \
>      -e '/^#/p' \
>      -e '/^Thread/p'
> 
> 
> This is the interest part in the pstack, rest is cosmetic.
> 
> pstack uses:
> # pstack 1
> 
> #0  0x00007fa18cf44017 in epoll_wait () from /lib64/libc.so.6
> #1  0x00007fa18e67e036 in sd_event_wait () from 
> /usr/lib/systemd/libsystemd-shared-239.so
> #2  0x00007fa18e67f33b in sd_event_run () from 
> /usr/lib/systemd/libsystemd-shared-239.so
> #3  0x000055c155da8c22 in manager_loop ()
> #4  0x000055c155d5f133 in main ()
> 
> Reproduction:
> 
> The debugged application generally attached to process by:
> gdb -p <<pid>>
> or gdb /proc/<<pid>>/exe pid
> pstack uses the latter  method to attach the debugged to gdb. If the
> application is large or process of reading symbols is slow, gives a good
> window to press the ctrl+c during attach. Spawning "gdb" under "strace
> -k" makes gdb a lot slower and gives a larger window to easily press the
> ctrl+c at the precise period i.e. during the attach of the debugged
> process. The above strace hack will enhance rate of reproduction of the
> issue. Testcase:
> 
> With GDB 13.1
> ps aux | grep abrtd
> root     2195168   /usr/sbin/abrtd -d -s
> 
> #strace -k -o log gdb -p 2195168
> Attaching to process 2195168
> [New LWP 2195177]
> [New LWP 2195179]
> ^C[Thread debugging using libthread_db enabled]
> <<<<   Note the ctrl+c is pressed after attach is initiated and it’s
> still reading the symbols from library >>>> Using host libthread_db
> library "/lib64/libthread_db.so.1".
> 0x00007fe3ed6d70d1 in poll () from /lib64/libc.so.6
> (gdb) q
> A debugging session is active.
>             Inferior 1 [process 2195168] will be detached Quit anyway? (y
> or n) y Detaching from program: /usr/sbin/abrtd, process 2195168
> 
> # ps aux | grep 2195168
> <<<< Process exited >>>>
> 
> This is having a very narrow window to press the ctrlc.
> Session1 :
> 
> ]$ ps aux | grep abrtd
> root        1329  0.0  0.0 602624 13076 ?        Ssl  May03   0:00 
> /usr/sbin/abrtd -d -s
> 
> Session2:
> 
> # ./tpstack 1329
> 
> + strace -o omlog -k ./gdb --quiet -nx -ex 'set width 0' -ex 'set height 
> 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all 
> bt' -ex quit /proc/1329/exe 1329
> Reading symbols from /proc/1329/exe...
> Python Exception <class 'AttributeError'>: module 'gdb' has no attribute 
> '_handle_missing_debuginfo'
> Reading symbols from .gnu_debugdata for /usr/sbin/abrtd...
> (No debugging symbols found in .gnu_debugdata for /usr/sbin/abrtd)
> Attaching to program: /proc/1329/exe, process 1329
> [New LWP 1399]
> [New LWP 1349] ^C
> 
> Session1:
> [opc@pssatapa-ol8 TEST]$ ps aux | grep abrtd
> <<<1329 Is killed >>>
> 
> This is a very small window, so a heavy application is good for 
> reproduction. I modified the the last part of pstack like:
> # Run GDB, strip out unwanted noise.
> # --readnever is no longer used since .gdb_index is now in use.
> strace -o omlog -k  ./gdb  --quiet -nx  -ex 'set width 0' -ex 'set 
> height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread 
> apply all bt' -ex quit  /proc/$1/exe $1
> 
> The strace with -k on gdb make gdb slow and we get a window to press 
> Ctrl+c.  otherwise the window is very small to time the signal. We 
> observe the problem while the FileStsyem or Kernel or proc FS is slow.
> 
> The signal is not intended to the inferior.
> The signal is passed from "gdb" to the inferior.
> 
> The SIGINT handler in gdb, marks the QUIT flag and
> in some paths we check the quit flag and pass the signal to inferior.
> That is killing the inferior.
> 
> On :
> +  check_quit_flag();
> This should be set only when inf->attach_flag is true.
> I will add the check in next iteration.
> The idea here is to clear any pending QUIT flag set by sigint
> else, post we set the sync_flag , a check to QUIT Flag
> and can kill the inferior.
> 
> Thanks
> Partha

Hi Pedro,

I do understand the last reply way a bit long to explain you the 
context. Please find the answers to your questions.

Here are the questions:
 >  - If you ctrl-c to abort the attach, do we really abort the
 >    attach properly?  Or do we stay attached in some half broken state?
 >
Let take the case of "gdb -p pid" and press a ctrl + c immediately.
The intention is to kill the gdb , not to abort the attachment or
kill the attached pid. In the problem case debugged process is killed.

 >  - Below you mention pstack, where can we find it?  And you mention
 >    that ctrl-c is pressed while that is printing a stack.  I'm assuming
 >    that's a backtrace command.  I'm confused in that case, as if that is
 >    so, then we should already be past the initial attach.  The question
 >    would then becomes, shouldn't gdb have the terminal at that point?
 >    How come it does not?

pstack is a wrapper over gdb and run as:
gdb --quiet -nx -ex 'set width 0' -ex 'set height
0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all
bt' -ex quit /proc/<<pid>/exe <<pid>>

Here gdb is run with -"ex" so so it does not need the gdb prompt to 
issue the "back trace" command.

The Ctrl+C is issued in a window between initial attach and 
target_post_attach.

 >This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does that 
 >manage to trigger the exit of the inferior at all?  ptrace should 
 >intercept the SIGINT before the inferior ever sees it.  Did it not?

/* Handle a SIGINT.  */
void
handle_sigint (int sig)
{
   signal (sig, handle_sigint);

   /* We could be running in a loop reading in symfiles or something so
      it may be quite a while before we get back to the event loop.  So
      set quit_flag to 1 here.  Then if QUIT is called before we get to
      the event loop, we will unwind as expected.  */
   set_quit_flag ();

In the problem case, gdb is reading the sysmbol files and we received 
the sigint. We set the quit flag in this context.

In the event loop we check the quit flag (check_quit_flag) and pass the 
signal to the inferior with "child_pass_ctrlc". This kills the target.

Its fine when gdb has the "GDB" prompt and it owns the terminal and we 
once we press Ctrl+C and that is passed to the target. But with -"ex" 
option, use never experience the GDB prompt and the signal should only 
kill gdb not the attached.

Best way to visualize the issue is to run:
gdb --quiet -nx -ex 'set width 0' -ex 'set height 0' -ex 'set pagination 
no' -ex 'set confirm off' -ex 'thread apply all  bt' -ex quit /proc/1/exe 1

and we have a sigint (Ctrl+C) while gdb reading the symbol files.

Thanks
Partha
  
Partha Satapathy June 10, 2024, 5:41 a.m. UTC | #6
On 6/3/2024 10:51 AM, Partha Satapathy wrote:
> On 5/16/2024 12:45 PM, Partha Satapathy wrote:
>> On 5/13/2024 8:19 PM, Pedro Alves wrote:
>>> Adding another question to the list below.  (I haven't tried to 
>>> reproduce this yet myself, btw.)
>>>
>>> On 2024-05-10 21:19, Pedro Alves wrote:
>>>> Hi.
>>>>
>>>> Just wanted to let you know that I've read all the discussion around 
>>>> this until this
>>>> email I'm replying to, and started thinking about it a bit. 
>>>> Unfortunately this is one of
>>>> those areas in GDB where the right change is rarely immediately 
>>>> obvious (to me).
>>>>
>>>> Some questions:
>>>>
>>>>   - If you ctrl-c to abort the attach, do we really abort the
>>>>     attach properly?  Or do we stay attached in some half broken state?
>>>>
>>>>   - Below you mention pstack, where can we find it?  And you mention
>>>>     that ctrl-c is pressed while that is printing a stack.  I'm 
>>>> assuming
>>>>     that's a backtrace command.  I'm confused in that case, as if 
>>>> that is
>>>>     so, then we should already be past the initial attach.  The 
>>>> question
>>>>     would then becomes, shouldn't gdb have the terminal at that point?
>>>>     How come it does not?
>>>
>>> #3 - The patch description states:
>>>
>>>   > Problem: While gdb is attaching an inferior, if ctrl-c is pressed 
>>> in the
>>>   > middle of the process attach,  the sigint is passed to the debugged
>>>   > process.  This triggers the exit of the inferior.
>>>
>>> This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does 
>>> that manage
>>> to trigger the exit of the inferior at all?  ptrace should intercept the
>>> SIGINT before the inferior ever sees it.  Did it not?
>>>
>>> Or could it be that the real issue is that because that sends the SIGINT
>>> to all the processes in the inferior's pgrp, we kill more processes than
>>> the one we're attaching to, and those processes exiting cause the 
>>> inferior
>>> to exit as well.  If so, then this is orthogonal to the initial attach,
>>> and can happen after the attach as well.  There is a bug open about this
>>> on bugzilla.
>>>
>>> Pedro Alves
>>>
>>>>
>>>> I'm wondering whether Baris's patch to eliminate the inferior
>>>> continuations would help with this, as it probably makes the attaching
>>>> sequence synchronous.  I should probably look at that one.
>>>>
>>>> Pedro Alves
>>>>
>>
>>
>> Thanks Pedro and Tom for reviewing the problem.
>>
>>
>> Problem :
>> pstack,  dumps the stack of all threads in a process. In some cases 
>> printing of stack can take significant time and ctrl-c is pressed to 
>> abort pstack/gdb application. This in turn kills the debugged process, 
>> which can be  critical for the system. In this case the intention of 
>> “ctrl+c” to kill pstack/gdb, but not the target application.
>>
>>
>> # tail pstack -n 12
>>
>> # Run GDB, strip out unwanted noise.
>> # --readnever is no longer used since .gdb_index is now in use.
>> $GDB --quiet -nx $GDBARGS /proc/$1/exe $1 <<EOF 2>&1 |
>> set width 0
>> set height 0
>> set pagination no
>> $backtrace
>> EOF
>> /bin/sed -n \
>>      -e 's/^\((gdb) \)*//' \
>>      -e '/^#/p' \
>>      -e '/^Thread/p'
>>
>>
>> This is the interest part in the pstack, rest is cosmetic.
>>
>> pstack uses:
>> # pstack 1
>>
>> #0  0x00007fa18cf44017 in epoll_wait () from /lib64/libc.so.6
>> #1  0x00007fa18e67e036 in sd_event_wait () from 
>> /usr/lib/systemd/libsystemd-shared-239.so
>> #2  0x00007fa18e67f33b in sd_event_run () from 
>> /usr/lib/systemd/libsystemd-shared-239.so
>> #3  0x000055c155da8c22 in manager_loop ()
>> #4  0x000055c155d5f133 in main ()
>>
>> Reproduction:
>>
>> The debugged application generally attached to process by:
>> gdb -p <<pid>>
>> or gdb /proc/<<pid>>/exe pid
>> pstack uses the latter  method to attach the debugged to gdb. If the
>> application is large or process of reading symbols is slow, gives a good
>> window to press the ctrl+c during attach. Spawning "gdb" under "strace
>> -k" makes gdb a lot slower and gives a larger window to easily press the
>> ctrl+c at the precise period i.e. during the attach of the debugged
>> process. The above strace hack will enhance rate of reproduction of the
>> issue. Testcase:
>>
>> With GDB 13.1
>> ps aux | grep abrtd
>> root     2195168   /usr/sbin/abrtd -d -s
>>
>> #strace -k -o log gdb -p 2195168
>> Attaching to process 2195168
>> [New LWP 2195177]
>> [New LWP 2195179]
>> ^C[Thread debugging using libthread_db enabled]
>> <<<<   Note the ctrl+c is pressed after attach is initiated and it’s
>> still reading the symbols from library >>>> Using host libthread_db
>> library "/lib64/libthread_db.so.1".
>> 0x00007fe3ed6d70d1 in poll () from /lib64/libc.so.6
>> (gdb) q
>> A debugging session is active.
>>             Inferior 1 [process 2195168] will be detached Quit anyway? (y
>> or n) y Detaching from program: /usr/sbin/abrtd, process 2195168
>>
>> # ps aux | grep 2195168
>> <<<< Process exited >>>>
>>
>> This is having a very narrow window to press the ctrlc.
>> Session1 :
>>
>> ]$ ps aux | grep abrtd
>> root        1329  0.0  0.0 602624 13076 ?        Ssl  May03   0:00 
>> /usr/sbin/abrtd -d -s
>>
>> Session2:
>>
>> # ./tpstack 1329
>>
>> + strace -o omlog -k ./gdb --quiet -nx -ex 'set width 0' -ex 'set 
>> height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread 
>> apply all bt' -ex quit /proc/1329/exe 1329
>> Reading symbols from /proc/1329/exe...
>> Python Exception <class 'AttributeError'>: module 'gdb' has no 
>> attribute '_handle_missing_debuginfo'
>> Reading symbols from .gnu_debugdata for /usr/sbin/abrtd...
>> (No debugging symbols found in .gnu_debugdata for /usr/sbin/abrtd)
>> Attaching to program: /proc/1329/exe, process 1329
>> [New LWP 1399]
>> [New LWP 1349] ^C
>>
>> Session1:
>> [opc@pssatapa-ol8 TEST]$ ps aux | grep abrtd
>> <<<1329 Is killed >>>
>>
>> This is a very small window, so a heavy application is good for 
>> reproduction. I modified the the last part of pstack like:
>> # Run GDB, strip out unwanted noise.
>> # --readnever is no longer used since .gdb_index is now in use.
>> strace -o omlog -k  ./gdb  --quiet -nx  -ex 'set width 0' -ex 'set 
>> height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread 
>> apply all bt' -ex quit  /proc/$1/exe $1
>>
>> The strace with -k on gdb make gdb slow and we get a window to press 
>> Ctrl+c.  otherwise the window is very small to time the signal. We 
>> observe the problem while the FileStsyem or Kernel or proc FS is slow.
>>
>> The signal is not intended to the inferior.
>> The signal is passed from "gdb" to the inferior.
>>
>> The SIGINT handler in gdb, marks the QUIT flag and
>> in some paths we check the quit flag and pass the signal to inferior.
>> That is killing the inferior.
>>
>> On :
>> +  check_quit_flag();
>> This should be set only when inf->attach_flag is true.
>> I will add the check in next iteration.
>> The idea here is to clear any pending QUIT flag set by sigint
>> else, post we set the sync_flag , a check to QUIT Flag
>> and can kill the inferior.
>>
>> Thanks
>> Partha
> 
> Hi Pedro,
> 
> I do understand the last reply way a bit long to explain you the 
> context. Please find the answers to your questions.
> 
> Here are the questions:
>  >  - If you ctrl-c to abort the attach, do we really abort the
>  >    attach properly?  Or do we stay attached in some half broken state?
>  >
> Let take the case of "gdb -p pid" and press a ctrl + c immediately.
> The intention is to kill the gdb , not to abort the attachment or
> kill the attached pid. In the problem case debugged process is killed.
> 
>  >  - Below you mention pstack, where can we find it?  And you mention
>  >    that ctrl-c is pressed while that is printing a stack.  I'm assuming
>  >    that's a backtrace command.  I'm confused in that case, as if that is
>  >    so, then we should already be past the initial attach.  The question
>  >    would then becomes, shouldn't gdb have the terminal at that point?
>  >    How come it does not?
> 
> pstack is a wrapper over gdb and run as:
> gdb --quiet -nx -ex 'set width 0' -ex 'set height
> 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all
> bt' -ex quit /proc/<<pid>/exe <<pid>>
> 
> Here gdb is run with -"ex" so so it does not need the gdb prompt to 
> issue the "back trace" command.
> 
> The Ctrl+C is issued in a window between initial attach and 
> target_post_attach.
> 
>  >This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does that 
>  >manage to trigger the exit of the inferior at all?  ptrace should 
>  >intercept the SIGINT before the inferior ever sees it.  Did it not?
> 
> /* Handle a SIGINT.  */
> void
> handle_sigint (int sig)
> {
>    signal (sig, handle_sigint);
> 
>    /* We could be running in a loop reading in symfiles or something so
>       it may be quite a while before we get back to the event loop.  So
>       set quit_flag to 1 here.  Then if QUIT is called before we get to
>       the event loop, we will unwind as expected.  */
>    set_quit_flag ();
> 
> In the problem case, gdb is reading the sysmbol files and we received 
> the sigint. We set the quit flag in this context.
> 
> In the event loop we check the quit flag (check_quit_flag) and pass the 
> signal to the inferior with "child_pass_ctrlc". This kills the target.
> 
> Its fine when gdb has the "GDB" prompt and it owns the terminal and we 
> once we press Ctrl+C and that is passed to the target. But with -"ex" 
> option, use never experience the GDB prompt and the signal should only 
> kill gdb not the attached.
> 
> Best way to visualize the issue is to run:
> gdb --quiet -nx -ex 'set width 0' -ex 'set height 0' -ex 'set pagination 
> no' -ex 'set confirm off' -ex 'thread apply all  bt' -ex quit /proc/1/exe 1
> 
> and we have a sigint (Ctrl+C) while gdb reading the symbol files.
> 
> Thanks
> Partha

Hi GDB team ,

Can you please update on this.

Thanks
Partha
  
Pedro Alves June 14, 2024, 5:19 p.m. UTC | #7
Hi!

Sorry for the delay.

On 2024-06-03 06:21, Partha Satapathy wrote:

> I do understand the last reply way a bit long to explain you the context. Please find the answers to your questions.
> 
> Here are the questions:
>>  - If you ctrl-c to abort the attach, do we really abort the
>>    attach properly?  Or do we stay attached in some half broken state?
>>
> Let take the case of "gdb -p pid" and press a ctrl + c immediately.
> The intention is to kill the gdb , not to abort the attachment or
> kill the attached pid. In the problem case debugged process is killed.

The question was really, even with your patch, when we Ctrl-C and that
aborts the attach, if GDB doesn't exit, are we in a good state?  Did
we detach properly?

> 
>>  - Below you mention pstack, where can we find it?  And you mention
>>    that ctrl-c is pressed while that is printing a stack.  I'm assuming
>>    that's a backtrace command.  I'm confused in that case, as if that is
>>    so, then we should already be past the initial attach.  The question
>>    would then becomes, shouldn't gdb have the terminal at that point?
>>    How come it does not?
> 
> pstack is a wrapper over gdb and run as:
> gdb --quiet -nx -ex 'set width 0' -ex 'set height
> 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all
> bt' -ex quit /proc/<<pid>/exe <<pid>>
> 
> Here gdb is run with -"ex" so so it does not need the gdb prompt to issue the "back trace" command.
> 
> The Ctrl+C is issued in a window between initial attach and target_post_attach.
> 
>>This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does that >manage to trigger the exit of the inferior at all?  ptrace should >intercept the SIGINT before the inferior ever sees it.  Did it not?

This question ^^^ was the most important.  I didn't see an answer for it.

> 
> /* Handle a SIGINT.  */
> void
> handle_sigint (int sig)
> {
>   signal (sig, handle_sigint);
> 
>   /* We could be running in a loop reading in symfiles or something so
>      it may be quite a while before we get back to the event loop.  So
>      set quit_flag to 1 here.  Then if QUIT is called before we get to
>      the event loop, we will unwind as expected.  */
>   set_quit_flag ();
> 
> In the problem case, gdb is reading the sysmbol files and we received the sigint. We set the quit flag in this context.
> 
> In the event loop we check the quit flag (check_quit_flag) and pass the signal to the inferior with "child_pass_ctrlc". This kills the target.

child_pass_ctrlc "kills" the target in the sense that it uses "kill(.., SIGINT)".  But that
should _not_ make process actually die!  If we are already attached to the process,
then ptrace should intercept the SIGINT, linux-nat.c:linux_nat_target::wait should see
the kernel reporting the SIGINT stop out of waitpid.  The only way it really makes the
inferior die if _after_ that, we somehow pass the signal to the inferior, with
"ptrace(PTRACE_CONTINUE, pid, ..., SIGINT)".  Did _that_ happen?  If so, where, how?
We need to understand exactly what is going on before we even think about what
a fix should look like.

> 
> Its fine when gdb has the "GDB" prompt and it owns the terminal and we once we press Ctrl+C and that is passed to the target. But with -"ex" option, use never experience the GDB prompt and the signal should only kill gdb not the attached.
> 
> Best way to visualize the issue is to run:
> gdb --quiet -nx -ex 'set width 0' -ex 'set height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all  bt' -ex quit /proc/1/exe 1
> 
> and we have a sigint (Ctrl+C) while gdb reading the symbol files.

I tried to reproduce by attaching to a "/usr/bin/sleep 10000" process,
but gdb reads debug info (or really, no debug info at all to read),
so I added a hack to gdb to sleep a bit to give me time to ctrl-c:

diff --git c/gdb/symfile.c w/gdb/symfile.c
index 5a03def91c6..69b475131b2 100644
--- c/gdb/symfile.c
+++ w/gdb/symfile.c
@@ -1072,6 +1072,9 @@ symbol_file_add_with_addrs (const gdb_bfd_ref_ptr &abfd, const char *name,
       else
        gdb_printf (_("Reading symbols from %ps...\n"),
                    styled_string (file_name_style.style (), name));
+
+      gdb_printf (_("Sleeping, press ctrl-c...\n"));
+      sleep (3);
     }
   syms_from_objfile (objfile, addrs, add_flags);


Still, I wasn't able to reproduce what you see:

$ /path/to/current/master/gdb --quiet -nx -ex 'set width 0' -ex 'set height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all bt' -ex quit /proc/2621255/exe 2621255
Reading symbols from /proc/2621255/exe...
Sleeping, press ctrl-c...
^CQuit
Attaching to program: /proc/2621255/exe, process 2621255
Error reading attached process's symbol file.
: No such file or directory.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Sleeping, press ctrl-c...
Reading symbols from /usr/lib/debug/.build-id/49/0fef8403240c91833978d494d39e537409b92e.debug...
Sleeping, press ctrl-c...
^CReading symbols from /lib64/ld-linux-x86-64.so.2...
Sleeping, press ctrl-c...
^CReading symbols from /usr/lib/debug/.build-id/41/86944c50f8a32b47d74931e3f512b811813b64.debug...
Sleeping, press ctrl-c...
^C[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x000074a84dee578a in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7ffd69aa9540, rem=0x7ffd69aa9530)
    at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78

warning: 78     ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory

Thread 1 (Thread 0x74a84e03b740 (LWP 2621255) "sleep"):
#0  0x000074a84dee578a in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7ffd69aa9540, rem=0x7ffd69aa9530) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
#1  0x000074a84deea677 in __GI___nanosleep (req=<optimized out>, rem=<optimized out>) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2  0x00006119b1d789f0 in ?? ()
#3  0x0000000000000000 in ?? ()
Detaching from program: /proc/2621255/exe, process 2621255
[Inferior 1 (process 2621255) detached]

I tried this multiple times, and the inferior process never died.

Pedro Alves
  
Partha Satapathy June 20, 2024, 7:24 a.m. UTC | #8
On 6/14/2024 10:49 PM, Pedro Alves wrote:
> Hi!
> 
> Sorry for the delay.
> 
> On 2024-06-03 06:21, Partha Satapathy wrote:
> 
>> I do understand the last reply way a bit long to explain you the context. Please find the answers to your questions.
>>
>> Here are the questions:
>>>    - If you ctrl-c to abort the attach, do we really abort the
>>>      attach properly?  Or do we stay attached in some half broken state?
>>>
>> Let take the case of "gdb -p pid" and press a ctrl + c immediately.
>> The intention is to kill the gdb , not to abort the attachment or
>> kill the attached pid. In the problem case debugged process is killed.
> 
> The question was really, even with your patch, when we Ctrl-C and that
> aborts the attach, if GDB doesn't exit, are we in a good state?  Did
> we detach properly?
> 
>>
>>>    - Below you mention pstack, where can we find it?  And you mention
>>>      that ctrl-c is pressed while that is printing a stack.  I'm assuming
>>>      that's a backtrace command.  I'm confused in that case, as if that is
>>>      so, then we should already be past the initial attach.  The question
>>>      would then becomes, shouldn't gdb have the terminal at that point?
>>>      How come it does not?
>>
>> pstack is a wrapper over gdb and run as:
>> gdb --quiet -nx -ex 'set width 0' -ex 'set height
>> 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all
>> bt' -ex quit /proc/<<pid>/exe <<pid>>
>>
>> Here gdb is run with -"ex" so so it does not need the gdb prompt to issue the "back trace" command.
>>
>> The Ctrl+C is issued in a window between initial attach and target_post_attach.
>>
>>> This SIGINT passing is done with "kill(-pgrp, SIGINT)".  How does that >manage to trigger the exit of the inferior at all?  ptrace should >intercept the SIGINT before the inferior ever sees it.  Did it not?
> 
> This question ^^^ was the most important.  I didn't see an answer for it.
> 
>>
>> /* Handle a SIGINT.  */
>> void
>> handle_sigint (int sig)
>> {
>>    signal (sig, handle_sigint);
>>
>>    /* We could be running in a loop reading in symfiles or something so
>>       it may be quite a while before we get back to the event loop.  So
>>       set quit_flag to 1 here.  Then if QUIT is called before we get to
>>       the event loop, we will unwind as expected.  */
>>    set_quit_flag ();
>>
>> In the problem case, gdb is reading the sysmbol files and we received the sigint. We set the quit flag in this context.
>>
>> In the event loop we check the quit flag (check_quit_flag) and pass the signal to the inferior with "child_pass_ctrlc". This kills the target.
> 
> child_pass_ctrlc "kills" the target in the sense that it uses "kill(.., SIGINT)".  But that
> should _not_ make process actually die!  If we are already attached to the process,
> then ptrace should intercept the SIGINT, linux-nat.c:linux_nat_target::wait should see
> the kernel reporting the SIGINT stop out of waitpid.  The only way it really makes the
> inferior die if _after_ that, we somehow pass the signal to the inferior, with
> "ptrace(PTRACE_CONTINUE, pid, ..., SIGINT)".  Did _that_ happen?  If so, where, how?
> We need to understand exactly what is going on before we even think about what
> a fix should look like.
> 
>>
>> Its fine when gdb has the "GDB" prompt and it owns the terminal and we once we press Ctrl+C and that is passed to the target. But with -"ex" option, use never experience the GDB prompt and the signal should only kill gdb not the attached.
>>
>> Best way to visualize the issue is to run:
>> gdb --quiet -nx -ex 'set width 0' -ex 'set height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all  bt' -ex quit /proc/1/exe 1
>>
>> and we have a sigint (Ctrl+C) while gdb reading the symbol files.
> 
> I tried to reproduce by attaching to a "/usr/bin/sleep 10000" process,
> but gdb reads debug info (or really, no debug info at all to read),
> so I added a hack to gdb to sleep a bit to give me time to ctrl-c:
> 
> diff --git c/gdb/symfile.c w/gdb/symfile.c
> index 5a03def91c6..69b475131b2 100644
> --- c/gdb/symfile.c
> +++ w/gdb/symfile.c
> @@ -1072,6 +1072,9 @@ symbol_file_add_with_addrs (const gdb_bfd_ref_ptr &abfd, const char *name,
>         else
>          gdb_printf (_("Reading symbols from %ps...\n"),
>                      styled_string (file_name_style.style (), name));
> +
> +      gdb_printf (_("Sleeping, press ctrl-c...\n"));
> +      sleep (3);
>       }
>     syms_from_objfile (objfile, addrs, add_flags);
> 
> 
> Still, I wasn't able to reproduce what you see:
> 
> $ /path/to/current/master/gdb --quiet -nx -ex 'set width 0' -ex 'set height 0' -ex 'set pagination no' -ex 'set confirm off' -ex 'thread apply all bt' -ex quit /proc/2621255/exe 2621255
> Reading symbols from /proc/2621255/exe...
> Sleeping, press ctrl-c...
> ^CQuit
> Attaching to program: /proc/2621255/exe, process 2621255
> Error reading attached process's symbol file.
> : No such file or directory.
> Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
> Sleeping, press ctrl-c...
> Reading symbols from /usr/lib/debug/.build-id/49/0fef8403240c91833978d494d39e537409b92e.debug...
> Sleeping, press ctrl-c...
> ^CReading symbols from /lib64/ld-linux-x86-64.so.2...
> Sleeping, press ctrl-c...
> ^CReading symbols from /usr/lib/debug/.build-id/41/86944c50f8a32b47d74931e3f512b811813b64.debug...
> Sleeping, press ctrl-c...
> ^C[Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x000074a84dee578a in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7ffd69aa9540, rem=0x7ffd69aa9530)
>      at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
> 
> warning: 78     ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory
> 
> Thread 1 (Thread 0x74a84e03b740 (LWP 2621255) "sleep"):
> #0  0x000074a84dee578a in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7ffd69aa9540, rem=0x7ffd69aa9530) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
> #1  0x000074a84deea677 in __GI___nanosleep (req=<optimized out>, rem=<optimized out>) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
> #2  0x00006119b1d789f0 in ?? ()
> #3  0x0000000000000000 in ?? ()
> Detaching from program: /proc/2621255/exe, process 2621255
> [Inferior 1 (process 2621255) detached]
> 
> I tried this multiple times, and the inferior process never died.
> 
> Pedro Alves
> 


Hi Pedro,
Thanks for looking in to this.

Console 1:
------------------------------------------------------
./gdb -v
GNU gdb (GDB) 16.0.50.20240605-git



# ./inf &
[1] 63855
# gdb -p 63855
(gdb) c
Continuing.

Console2:
-----------------------------------------------------
# cat /proc/63855/task/63855/stat
63855 (inf) R
# kill -2 63855

Console 1:
------------------------------------------------------
Program received signal SIGINT, Interrupt.
0x000000000040053a in main ()
(gdb)
Console2:
-----------------------------------------------------
# cat /proc/63855/task/63855/stat
cat /proc/63855/task/63855/stat
63855 (inf)

Console 1:
------------------------------------------------------
Program received signal SIGINT, Interrupt.
0x000000000040053a in main ()
(gdb) c
Continuing.

(gdb) q
A debugging session is active.
         Inferior 1 [process 63855] will be detached.
Quit anyway? (y or n) y
Detaching from program: /home/opc/BLD/HTTP_GDB_ML/VN/T/inf, process 63855
[Inferior 1 (process 63855) detached]
]# ps aux | grep 63855
root       63855 39.1  0.0   4232   916 pts/2    R    05:37   3:42 ./inf


This is the pass case, and here:  The  “inf” process PID 63855  is 
running (R state) , Shell queued the sigint to process 63855. As process 
63855 is running handled sigint and sent the notification
(sigchild) to Debugger.  GDB handle the sigchild and report the sigint 
on the debugged. GDB masks the sigint on the child and execution 
continues. After quit , the process continues with  running state.


Similarly :
# ./inf&
[1] 123586
# gdb -p 123586
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x000000000040053a in main ()
(gdb)c
(gdb) q
A debugging session is active.
         Inferior 1 [process 123586] will be detached.
Quit anyway? (y or n) y
Detaching from program: inf, process 123586
[Inferior 1 (process 123586) detached]

We pressed Ctrl+C gdb passes the sigint to debugged with 
child_pass_ctrlc, debugged received the sigint. it’s in running state, 
sent the sigchld to gdb and stopped. gdb handle sigchld after quit 
debugged  continued with running  state.


In the fail case :
Console 1:
------------------------------------------------------
#gdb -p 63855
(gdb)

Console 2:
------------------------------------------------------
# cat /proc/63855/task/63855/stat
63855 (inf) t
# kill -2 63855

Console 1:
------------------------------------------------------
0x000000000040053a in main ()
(gdb)

(gdb) q
A debugging session is active.
         Inferior 1 [process 63855] will be detached.
Quit anyway? (y or n) y
Detaching from program: inf, process 63855
[Inferior 1 (process 63855) detached]
[1]+  Interrupt               ./inf
# ps aux | grep 63855
<< 63855 is killed >>

The  “inf” process PID 63855  is ptrace stop state  (t state) . Shell 
queued the sigint to process 63855. As process 63855 is stop state, did 
not act to the signal. “gdb” never received sigchild from  the child 
sigint context and no action taken. After quit , the process starts 
running and executes the normal sigint path and exit.

In my case:
./gdb  -ex 'thread apply all bt' -ex quit  /proc/<<pid>>/exe <<pid>>
There is no interactive debugger or cont command here. We print the 
stack and quit. Hence the process never need to go to running state to 
handle the “sigint” till detach.

If we press a Ctrl+C in while the symbol reading :
./gdb  -ex 'thread apply all bt' -ex quit  /proc/<<pid>>/exe <<pid>>
^CReading symbols from /proc/2888105/exe...
At this time PTRACE_ATTACH is done from gdb, and symbols are read after 
that. gdb receives the sigint and passes it to the debugged by 
child_pass_ctrlc. Debugged is in stop state from the start and did not 
response to the sigint. After quit PTRACE_DETACH, process handles the 
pending sigint and exit.


I am attaching some snip of strace OP from my  reproduction :
1.ptrace attach:

  123833 ptrace(PTRACE_ATTACH, 2888105)
  123835 gdb(inf_ptrace_target::attach
  123836 gdb(linux_nat_target::attach
  123837 gdb(attach_command(char const*,

2. GDB reading symbols with read_symbols, got sigint from “Ctrl+c” 
handle_sigint
and set the quit flag by set_quit_flag.

  270701  gdb(set_quit_flag()
  270702  gdb(handle_sigint(
  270708  gdb(elf_symfile_read(objfile*,
  270709  gdb(read_symbols(objfile*,

3. gdb continue with symbol file read.

  312569  gdb(elf_symfile_read(objfile*,
  312570  gdb(read_symbols(objfile*,

4. At some point , gdb pass the signal to the child.

  312759  gdb(child_pass_ctrlc(target_ops*)
  312760  gdb(target_pass_ctrlc()
  312761  gdb(target_read(
  312762  gdb(target_read_memory(unsigned long, unsigned char*,
  312763  gdb(read_program_header(int, int*, unsigned long*)
  312764  gdb(scan_dyntag_auxv(int, unsigned long*, unsigned long*)
  312765  gdb(elf_locate_base()

5. gdb did not receive the sigchild and continue with reading the symbol.

  316150  gdb(elf_symfile_read(objfile*,
  316151  gdb(read_symbols(objfile*, enum_flags<symfile_add_flag>)
  316154  gdb(add_vsyscall_page(inferior*)

6. at last ptrace detach happened and process is exited.
346819 ptrace(PTRACE_DETACH, 2888105, NULL, 0) = 0

You can try the with the simple experiment explained in “In the fail case :”
The only difference is the sigint is sent from shell rather than “gdb” . 
“gdb” will not react to the sigint if “continue command” is not applies.

“
child_pass_ctrlc "kills" the target in the sense that it uses "kill(.., 
SIGINT)".  But that should _not_ make process actually die!  If we are 
already attached to the process, then ptrace should intercept the 
SIGINT, linux-nat.c:linux_nat_target::wait should see the kernel 
reporting the SIGINT stop out of waitpid.  The only way it really makes 
the inferior die if _after_ that, we somehow pass the signal to the 
inferior, with "ptrace(PTRACE_CONTINUE, pid, ..., SIGINT)".  Did _that_ 
happen?  If so, where, how?
We need to understand exactly what is going on before we even think 
about what a fix should look like.\
“
Yes I agree with you on this. We should see :

  142357  > gdb(sigchld_handler
  142360  > gdb(child_pass_ctrlc(
  142361  > gdb(target_pass_ctrlc()

Followed by :
  142402  gdb(linux_nat_target::wait
  142403  gdb(target_wait(ptid_t, target_waitstatus*,
  142404  gdb(do_target_wait_1(inferior*, ptid_t, target_waitstatus*,
  142405  gdb(fetch_inferior_event()

This I can see in the cases where the debugged process is in running 
state, but not when debugged process is in ptrace stop state.

Thanks
Partha
  

Patch

diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index 0309658690c1..ee34498525fd 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -2510,6 +2510,8 @@  setup_inferior (int from_tty)
   target_post_attach (inferior_ptid.pid ());
 
   post_create_inferior (from_tty);
+  check_quit_flag();
+  current_inferior ()->sync_flag = true;
 }
 
 /* What to do after the first program stops after attaching.  */
diff --git a/gdb/inferior.h b/gdb/inferior.h
index e239aa5b3cf0..8f54db17a0de 100644
--- a/gdb/inferior.h
+++ b/gdb/inferior.h
@@ -603,6 +603,9 @@  class inferior : public refcounted_object,
   /* True if this child process was attached rather than forked.  */
   bool attach_flag = false;
 
+  /* True if inferior has been fully attached*/
+  bool sync_flag = false;
+
   /* If this inferior is a vfork child, then this is the pointer to
      its vfork parent, if GDB is still attached to it.  */
   inferior *vfork_parent = NULL;
diff --git a/gdb/inflow.c b/gdb/inflow.c
index 773ac0ba4997..381e6e4c22dd 100644
--- a/gdb/inflow.c
+++ b/gdb/inflow.c
@@ -585,6 +585,8 @@  child_pass_ctrlc (struct target_ops *self)
       if (inf->terminal_state != target_terminal_state::is_ours)
 	{
 	  gdb_assert (inf->pid != 0);
+	  if ((inf->attach_flag) && !(inf->sync_flag))
+	    return;
 
 #ifndef _WIN32
 	  kill (inf->pid, SIGINT);