* Mutual debugging of 2 processes can stuck in unkillable stopped state
@ 2021-03-29 15:28 Igor Zhbanov
2021-03-29 16:49 ` Oleg Nesterov
0 siblings, 1 reply; 7+ messages in thread
From: Igor Zhbanov @ 2021-03-29 15:28 UTC (permalink / raw)
To: linux-trace-devel, Oleg Nesterov
Mutual debugging of 2 processes can stuck in unkillable stopped state
Hi!
When one process, let's say "A", is tracing the another process "B", and the
process "B" is trying to attach to the process "A", then both of them are
getting stuck in the "t+" state. And they are ignoring all of the signals
including the SIGKILL, so it is not possible to terminate them without
a reboot.
To reproduce:
1) Run two terminals
2) Attach with "strace -p ..." from the first terminal to the shell (bash) of
the second terminal.
3) In the second terminal run "exec strace -p ..." to attach to the PID of the
first strace.
Then you'll see that the second strace is hanging without any output. And the
first strace will output following and hang too:
ptrace(PTRACE_SEIZE, 11795, NULL,
PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT
(The 11795 is the PID of the first strace itself.)
And in the process list you will see following:
ps awux | grep strace
user 11776 0.0 0.0 24752 2248 pts/3 t+ 13:53 0:00 strace -p 11795
user 11795 0.0 0.0 24752 3888 pts/1 t+ 13:54 0:00 strace -p 11776
I suppose that there should be some way to break the deadlocked debug. And the
system administrator must be able to terminate non-privileged processes.
Thank you.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state 2021-03-29 15:28 Mutual debugging of 2 processes can stuck in unkillable stopped state Igor Zhbanov @ 2021-03-29 16:49 ` Oleg Nesterov 2021-03-29 17:01 ` Igor Zhbanov 0 siblings, 1 reply; 7+ messages in thread From: Oleg Nesterov @ 2021-03-29 16:49 UTC (permalink / raw) To: Igor Zhbanov; +Cc: linux-trace-devel, linux-kernel On 03/29, Igor Zhbanov wrote: > > Mutual debugging of 2 processes can stuck in unkillable stopped state can't reproduce and can't understand... > Hi! > > When one process, let's say "A", is tracing the another process "B", and the > process "B" is trying to attach to the process "A", then both of them are > getting stuck in the "t+" state. And they are ignoring all of the signals > including the SIGKILL, Why do you think so? What is your kernel version? "t" means TASK_TRACED, SIGKILL should wake it up and terminate. > so it is not possible to terminate them without > a reboot. > > To reproduce: > 1) Run two terminals > 2) Attach with "strace -p ..." from the first terminal to the shell (bash) of > the second terminal. > 3) In the second terminal run "exec strace -p ..." to attach to the PID of the > first strace. > > Then you'll see that the second strace is hanging without any output. And the > first strace will output following and hang too: > ptrace(PTRACE_SEIZE, 11795, NULL, > PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT > > (The 11795 is the PID of the first strace itself.) > > And in the process list you will see following: > ps awux | grep strace > user 11776 0.0 0.0 24752 2248 pts/3 t+ 13:53 0:00 strace -p 11795 > user 11795 0.0 0.0 24752 3888 pts/1 t+ 13:54 0:00 strace -p 11776 OK, may be they sleep in PTRACE_EVENT_EXIT? After you tried to send SIGKILL? please show us the output from "cat /proc/{11795,11776}/stack". And "cat /proc/{11795,11776}/status" just in case. Oleg. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state 2021-03-29 16:49 ` Oleg Nesterov @ 2021-03-29 17:01 ` Igor Zhbanov 2021-03-29 17:38 ` Oleg Nesterov 0 siblings, 1 reply; 7+ messages in thread From: Igor Zhbanov @ 2021-03-29 17:01 UTC (permalink / raw) To: Oleg Nesterov; +Cc: linux-trace-devel, linux-kernel Hi Oleg! I've tried both 5.3.18 and 5.10.0. The behavior is the same. The important thing is to run "exec strace -p ..." on the second terminal to create the loop A->B->A. So the last line from the first strace we see is: ptrace(PTRACE_SEIZE, 1990, NULL, PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT I.e. it printed the syscall prior to its execution and hanged after the execution. izh@suse2:~> ps awux|grep strace izh 1891 0.0 0.0 24752 3828 pts/1 ts+ 19:52 0:00 strace -p 1990 izh 1990 0.0 0.0 24752 3628 pts/0 t+ 19:53 0:00 strace -p 1891 izh@suse2:~> kill 1990 1891 izh@suse2:~> kill -9 1990 1891 izh@suse2:~> sudo cat /proc/1891/stack [sudo] password for root: [<0>] ptrace_stop+0x14a/0x260 [<0>] ptrace_do_notify+0x91/0xb0 [<0>] ptrace_notify+0x4e/0x70 [<0>] do_exit+0x910/0xb70 [<0>] do_group_exit+0x3a/0xa0 [<0>] get_signal+0x124/0x800 [<0>] arch_do_signal_or_restart+0xa9/0x290 [<0>] exit_to_user_mode_prepare+0xe7/0x1a0 [<0>] syscall_exit_to_user_mode+0x18/0x40 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 izh@suse2:~> sudo cat /proc/1990/stack [<0>] ptrace_stop+0x14a/0x260 [<0>] ptrace_do_notify+0x91/0xb0 [<0>] ptrace_notify+0x4e/0x70 [<0>] do_exit+0x910/0xb70 [<0>] do_group_exit+0x3a/0xa0 [<0>] get_signal+0x124/0x800 [<0>] arch_do_signal_or_restart+0xa9/0x290 [<0>] exit_to_user_mode_prepare+0xe7/0x1a0 [<0>] syscall_exit_to_user_mode+0x18/0x40 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 izh@suse2:~> cat /proc/1891/status Name: strace Umask: 0022 State: t (tracing stop) Tgid: 1891 Ngid: 0 Pid: 1891 PPid: 1890 TracerPid: 1990 Uid: 1000 1000 1000 1000 Gid: 100 100 100 100 FDSize: 256 Groups: 100 NStgid: 1891 NSpid: 1891 NSpgid: 1891 NSsid: 1891 VmPeak: 24752 kB VmSize: 24752 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 3828 kB VmRSS: 3828 kB RssAnon: 520 kB RssFile: 3308 kB RssShmem: 0 kB VmData: 284 kB VmStk: 132 kB VmExe: 1108 kB VmLib: 2828 kB VmPTE: 80 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 0 THP_enabled: 1 Threads: 1 SigQ: 4/15639 SigPnd: 0000000000000000 ShdPnd: 0000000000014100 SigBlk: 0000000000002000 SigIgn: 0000000000300000 SigCgt: 0000000180007007 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 000001ffffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Seccomp_filters: 0 Speculation_Store_Bypass: vulnerable SpeculationIndirectBranch: always enabled Cpus_allowed: 7 Cpus_allowed_list: 0-2 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 1561 nonvoluntary_ctxt_switches: 7 izh@suse2:~> cat /proc/1990/status Name: strace Umask: 0022 State: t (tracing stop) Tgid: 1990 Ngid: 0 Pid: 1990 PPid: 1847 TracerPid: 1891 Uid: 1000 1000 1000 1000 Gid: 100 100 100 100 FDSize: 256 Groups: 100 NStgid: 1990 NSpid: 1990 NSpgid: 1990 NSsid: 1847 VmPeak: 24752 kB VmSize: 24752 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 3628 kB VmRSS: 3628 kB RssAnon: 520 kB RssFile: 3108 kB RssShmem: 0 kB VmData: 284 kB VmStk: 132 kB VmExe: 1108 kB VmLib: 2828 kB VmPTE: 88 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 0 THP_enabled: 1 Threads: 1 SigQ: 4/15639 SigPnd: 0000000000000000 ShdPnd: 0000000000014100 SigBlk: 0000000000002000 SigIgn: 0000000000300000 SigCgt: 0000000180007007 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 000001ffffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Seccomp_filters: 0 Speculation_Store_Bypass: vulnerable SpeculationIndirectBranch: always enabled Cpus_allowed: 7 Cpus_allowed_list: 0-2 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 180 nonvoluntary_ctxt_switches: 848 On 29.03.2021 19:49, Oleg Nesterov wrote: > On 03/29, Igor Zhbanov wrote: >> >> Mutual debugging of 2 processes can stuck in unkillable stopped state > > can't reproduce and can't understand... > >> Hi! >> >> When one process, let's say "A", is tracing the another process "B", and the >> process "B" is trying to attach to the process "A", then both of them are >> getting stuck in the "t+" state. And they are ignoring all of the signals >> including the SIGKILL, > > Why do you think so? What is your kernel version? > > "t" means TASK_TRACED, SIGKILL should wake it up and terminate. > >> so it is not possible to terminate them without >> a reboot. >> >> To reproduce: >> 1) Run two terminals >> 2) Attach with "strace -p ..." from the first terminal to the shell (bash) of >> the second terminal. >> 3) In the second terminal run "exec strace -p ..." to attach to the PID of the >> first strace. >> >> Then you'll see that the second strace is hanging without any output. And the >> first strace will output following and hang too: >> ptrace(PTRACE_SEIZE, 11795, NULL, >> PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT >> >> (The 11795 is the PID of the first strace itself.) >> >> And in the process list you will see following: >> ps awux | grep strace >> user 11776 0.0 0.0 24752 2248 pts/3 t+ 13:53 0:00 strace -p 11795 >> user 11795 0.0 0.0 24752 3888 pts/1 t+ 13:54 0:00 strace -p 11776 > > OK, may be they sleep in PTRACE_EVENT_EXIT? After you tried to send SIGKILL? > > please show us the output from "cat /proc/{11795,11776}/stack". And > "cat /proc/{11795,11776}/status" just in case. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state 2021-03-29 17:01 ` Igor Zhbanov @ 2021-03-29 17:38 ` Oleg Nesterov 2021-03-29 17:44 ` Igor Zhbanov 0 siblings, 1 reply; 7+ messages in thread From: Oleg Nesterov @ 2021-03-29 17:38 UTC (permalink / raw) To: Igor Zhbanov; +Cc: linux-trace-devel, linux-kernel Hi Igor, So. As expected, they sleep in EVENT_EXIT _after_ you have already sent SIGKILL. Oh. I can only repeat that PTRACE_EVENT_EXIT must die ;) Or at least we should finally define its semantics. Igor, thanks for your report, but (I think) this has nothing to do with mutual debugging. I'll return to this problem in a couple of days, I'm a bit busy right now. Thanks, Oleg. On 03/29, Igor Zhbanov wrote: > Hi Oleg! > > I've tried both 5.3.18 and 5.10.0. The behavior is the same. > The important thing is to run "exec strace -p ..." on the second terminal > to create the loop A->B->A. > > So the last line from the first strace we see is: > ptrace(PTRACE_SEIZE, 1990, NULL, PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT > > I.e. it printed the syscall prior to its execution and hanged after the > execution. > > izh@suse2:~> ps awux|grep strace > izh 1891 0.0 0.0 24752 3828 pts/1 ts+ 19:52 0:00 strace -p 1990 > izh 1990 0.0 0.0 24752 3628 pts/0 t+ 19:53 0:00 strace -p 1891 > > izh@suse2:~> kill 1990 1891 > izh@suse2:~> kill -9 1990 1891 > > izh@suse2:~> sudo cat /proc/1891/stack > [sudo] password for root: > [<0>] ptrace_stop+0x14a/0x260 > [<0>] ptrace_do_notify+0x91/0xb0 > [<0>] ptrace_notify+0x4e/0x70 > [<0>] do_exit+0x910/0xb70 > [<0>] do_group_exit+0x3a/0xa0 > [<0>] get_signal+0x124/0x800 > [<0>] arch_do_signal_or_restart+0xa9/0x290 > [<0>] exit_to_user_mode_prepare+0xe7/0x1a0 > [<0>] syscall_exit_to_user_mode+0x18/0x40 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > izh@suse2:~> sudo cat /proc/1990/stack > [<0>] ptrace_stop+0x14a/0x260 > [<0>] ptrace_do_notify+0x91/0xb0 > [<0>] ptrace_notify+0x4e/0x70 > [<0>] do_exit+0x910/0xb70 > [<0>] do_group_exit+0x3a/0xa0 > [<0>] get_signal+0x124/0x800 > [<0>] arch_do_signal_or_restart+0xa9/0x290 > [<0>] exit_to_user_mode_prepare+0xe7/0x1a0 > [<0>] syscall_exit_to_user_mode+0x18/0x40 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > izh@suse2:~> cat /proc/1891/status > Name: strace > Umask: 0022 > State: t (tracing stop) > Tgid: 1891 > Ngid: 0 > Pid: 1891 > PPid: 1890 > TracerPid: 1990 > Uid: 1000 1000 1000 1000 > Gid: 100 100 100 100 > FDSize: 256 > Groups: 100 > NStgid: 1891 > NSpid: 1891 > NSpgid: 1891 > NSsid: 1891 > VmPeak: 24752 kB > VmSize: 24752 kB > VmLck: 0 kB > VmPin: 0 kB > VmHWM: 3828 kB > VmRSS: 3828 kB > RssAnon: 520 kB > RssFile: 3308 kB > RssShmem: 0 kB > VmData: 284 kB > VmStk: 132 kB > VmExe: 1108 kB > VmLib: 2828 kB > VmPTE: 80 kB > VmSwap: 0 kB > HugetlbPages: 0 kB > CoreDumping: 0 > THP_enabled: 1 > Threads: 1 > SigQ: 4/15639 > SigPnd: 0000000000000000 > ShdPnd: 0000000000014100 > SigBlk: 0000000000002000 > SigIgn: 0000000000300000 > SigCgt: 0000000180007007 > CapInh: 0000000000000000 > CapPrm: 0000000000000000 > CapEff: 0000000000000000 > CapBnd: 000001ffffffffff > CapAmb: 0000000000000000 > NoNewPrivs: 0 > Seccomp: 0 > Seccomp_filters: 0 > Speculation_Store_Bypass: vulnerable > SpeculationIndirectBranch: always enabled > Cpus_allowed: 7 > Cpus_allowed_list: 0-2 > Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 > Mems_allowed_list: 0 > voluntary_ctxt_switches: 1561 > nonvoluntary_ctxt_switches: 7 > > izh@suse2:~> cat /proc/1990/status > Name: strace > Umask: 0022 > State: t (tracing stop) > Tgid: 1990 > Ngid: 0 > Pid: 1990 > PPid: 1847 > TracerPid: 1891 > Uid: 1000 1000 1000 1000 > Gid: 100 100 100 100 > FDSize: 256 > Groups: 100 > NStgid: 1990 > NSpid: 1990 > NSpgid: 1990 > NSsid: 1847 > VmPeak: 24752 kB > VmSize: 24752 kB > VmLck: 0 kB > VmPin: 0 kB > VmHWM: 3628 kB > VmRSS: 3628 kB > RssAnon: 520 kB > RssFile: 3108 kB > RssShmem: 0 kB > VmData: 284 kB > VmStk: 132 kB > VmExe: 1108 kB > VmLib: 2828 kB > VmPTE: 88 kB > VmSwap: 0 kB > HugetlbPages: 0 kB > CoreDumping: 0 > THP_enabled: 1 > Threads: 1 > SigQ: 4/15639 > SigPnd: 0000000000000000 > ShdPnd: 0000000000014100 > SigBlk: 0000000000002000 > SigIgn: 0000000000300000 > SigCgt: 0000000180007007 > CapInh: 0000000000000000 > CapPrm: 0000000000000000 > CapEff: 0000000000000000 > CapBnd: 000001ffffffffff > CapAmb: 0000000000000000 > NoNewPrivs: 0 > Seccomp: 0 > Seccomp_filters: 0 > Speculation_Store_Bypass: vulnerable > SpeculationIndirectBranch: always enabled > Cpus_allowed: 7 > Cpus_allowed_list: 0-2 > Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 > Mems_allowed_list: 0 > voluntary_ctxt_switches: 180 > nonvoluntary_ctxt_switches: 848 > > On 29.03.2021 19:49, Oleg Nesterov wrote: > >On 03/29, Igor Zhbanov wrote: > >> > >>Mutual debugging of 2 processes can stuck in unkillable stopped state > > > >can't reproduce and can't understand... > > > >>Hi! > >> > >>When one process, let's say "A", is tracing the another process "B", and the > >>process "B" is trying to attach to the process "A", then both of them are > >>getting stuck in the "t+" state. And they are ignoring all of the signals > >>including the SIGKILL, > > > >Why do you think so? What is your kernel version? > > > >"t" means TASK_TRACED, SIGKILL should wake it up and terminate. > > > >>so it is not possible to terminate them without > >>a reboot. > >> > >>To reproduce: > >>1) Run two terminals > >>2) Attach with "strace -p ..." from the first terminal to the shell (bash) of > >> the second terminal. > >>3) In the second terminal run "exec strace -p ..." to attach to the PID of the > >> first strace. > >> > >>Then you'll see that the second strace is hanging without any output. And the > >>first strace will output following and hang too: > >>ptrace(PTRACE_SEIZE, 11795, NULL, > >> PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT > >> > >>(The 11795 is the PID of the first strace itself.) > >> > >>And in the process list you will see following: > >>ps awux | grep strace > >>user 11776 0.0 0.0 24752 2248 pts/3 t+ 13:53 0:00 strace -p 11795 > >>user 11795 0.0 0.0 24752 3888 pts/1 t+ 13:54 0:00 strace -p 11776 > > > >OK, may be they sleep in PTRACE_EVENT_EXIT? After you tried to send SIGKILL? > > > >please show us the output from "cat /proc/{11795,11776}/stack". And > >"cat /proc/{11795,11776}/status" just in case. > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state 2021-03-29 17:38 ` Oleg Nesterov @ 2021-03-29 17:44 ` Igor Zhbanov 2021-04-12 7:25 ` Igor Zhbanov 0 siblings, 1 reply; 7+ messages in thread From: Igor Zhbanov @ 2021-03-29 17:44 UTC (permalink / raw) To: Oleg Nesterov; +Cc: linux-trace-devel, linux-kernel Hi Oleg, On 29.03.2021 20:38, Oleg Nesterov wrote: > Hi Igor, > > So. As expected, they sleep in EVENT_EXIT _after_ you have already > sent SIGKILL. Here is the processes stack before sending any signals to them: izh@suse2:~> sudo cat /proc/1751/stack [<0>] ptrace_stop+0x14e/0x260 [<0>] ptrace_do_notify+0x91/0xb0 [<0>] ptrace_notify+0x4e/0x70 [<0>] syscall_slow_exit_work+0x90/0x150 [<0>] do_syscall_64+0x129/0x1f0 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 izh@suse2:~> sudo cat /proc/1979/stack [<0>] ptrace_stop+0x14e/0x260 [<0>] get_signal+0x4d5/0x840 [<0>] do_signal+0x30/0x6a0 [<0>] exit_to_usermode_loop+0x8b/0x120 [<0>] do_syscall_64+0x1c3/0x1f0 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > Igor, thanks for your report, but (I think) this has nothing to do > with mutual debugging. I'll return to this problem in a couple of > days, I'm a bit busy right now. Sorry for inexact description. I said it from the user perspective when the processes are stopped and can't be killed. :-) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state 2021-03-29 17:44 ` Igor Zhbanov @ 2021-04-12 7:25 ` Igor Zhbanov 2021-04-13 17:17 ` Oleg Nesterov 0 siblings, 1 reply; 7+ messages in thread From: Igor Zhbanov @ 2021-04-12 7:25 UTC (permalink / raw) To: Oleg Nesterov; +Cc: linux-trace-devel, linux-kernel Hi Oleg, So what is the cause of this problem? Thank you. On 29.03.2021 20:44, Igor Zhbanov wrote: > > Here is the processes stack before sending any signals to them: > > izh@suse2:~> sudo cat /proc/1751/stack > [<0>] ptrace_stop+0x14e/0x260 > [<0>] ptrace_do_notify+0x91/0xb0 > [<0>] ptrace_notify+0x4e/0x70 > [<0>] syscall_slow_exit_work+0x90/0x150 > [<0>] do_syscall_64+0x129/0x1f0 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > izh@suse2:~> sudo cat /proc/1979/stack > [<0>] ptrace_stop+0x14e/0x260 > [<0>] get_signal+0x4d5/0x840 > [<0>] do_signal+0x30/0x6a0 > [<0>] exit_to_usermode_loop+0x8b/0x120 > [<0>] do_syscall_64+0x1c3/0x1f0 > [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> Igor, thanks for your report, but (I think) this has nothing to do >> with mutual debugging. I'll return to this problem in a couple of >> days, I'm a bit busy right now. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state 2021-04-12 7:25 ` Igor Zhbanov @ 2021-04-13 17:17 ` Oleg Nesterov 0 siblings, 0 replies; 7+ messages in thread From: Oleg Nesterov @ 2021-04-13 17:17 UTC (permalink / raw) To: Igor Zhbanov; +Cc: linux-trace-devel, linux-kernel Hi Igor, sorry for delay... On 04/12, Igor Zhbanov wrote: > > Hi Oleg, > > So what is the cause of this problem? The cause is clear. And well known ;) And again, this has almost nothing to do with the mutual debugging. The tracee sleeps in ptrace_stop(). You send SIGKILL. This wakes the tracee up, it dequeues the signal, calls do_exit(), and stops again in PTRACE_EVENT_EXIT. With SIGKILL in signal->shared_pending. This all looks as if the tracee doesn't react to SIGKILL. The only problem is that any change can break something which relies on the current behaviour :/ I'll write another email on this. Oleg. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-13 17:17 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-29 15:28 Mutual debugging of 2 processes can stuck in unkillable stopped state Igor Zhbanov 2021-03-29 16:49 ` Oleg Nesterov 2021-03-29 17:01 ` Igor Zhbanov 2021-03-29 17:38 ` Oleg Nesterov 2021-03-29 17:44 ` Igor Zhbanov 2021-04-12 7:25 ` Igor Zhbanov 2021-04-13 17:17 ` Oleg Nesterov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).