Re: [External] : Re: [PATCH v4] gdb : Signal to pstack/gdb kills the attached process.

[Partha Satapathy <partha.satapathy@oracle.com>]

On 3/26/2024 3:29 PM, Partha Satapathy wrote:
> On 3/7/2024 3:28 PM, Partha Satapathy wrote:
>> Author: Partha Sarathi Satapathy <partha.satapathy@oracle.com>
>> Date:   Fri Nov 17 09:18:56 2023 +0000
>>
>> gdb : Signal to pstack/gdb kills the attached process.
>>
>> 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.
>>
>> Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
>> ---
>>   gdb/infcmd.c   | 2 ++
>>   gdb/inferior.h | 3 +++
>>   gdb/target.c   | 3 +++
>>   3 files changed, 8 insertions(+)
>>
>> diff --git a/gdb/infcmd.c b/gdb/infcmd.c
>> index c1fdbb300c67..8ab2d50477f4 100644
>> --- a/gdb/infcmd.c
>> +++ b/gdb/infcmd.c
>> @@ -2528,6 +2528,8 @@ enum async_reply_reason
>>     target_post_attach (inferior_ptid.pid ());
>>
>>     post_create_inferior (from_tty);
>> +  current_inferior ()->sync_flag = true;
>> +  check_quit_flag();
>>   }
>>
>>   /* What to do after the first program stops after attaching.  */
>> diff --git a/gdb/inferior.h b/gdb/inferior.h
>> index 7be28423aeb1..a6065da19a87 100644
>> --- a/gdb/inferior.h
>> +++ b/gdb/inferior.h
>> @@ -600,6 +600,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 synced and prompt is no longer 
>> blocked */
>> +  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/target.c b/gdb/target.c
>> index bbc1badc9e19..7c7df9c2ed87 100644
>> --- a/gdb/target.c
>> +++ b/gdb/target.c
>> @@ -3794,6 +3794,9 @@ struct target_ops *
>>                   through the target_stack.  */
>>                scoped_restore_current_inferior restore_inferior;
>>                set_current_inferior (inf);
>> +             if ((current_inferior ()->attach_flag)
>> +               && !(current_inferior ()->sync_flag))
>> +                 return;
>>                current_inferior ()->top_target ()->pass_ctrlc ();
>>                return;
>>              }
> 

Hi GDB Team,

Can you update on this.

Thanks
Partha