Re: [PATCH 7/8] gdbserver: report correct status in thread stop race condition

Pedro Alves
2022-03-31T18:23:59Z

On 2022-01-17 16:27, Simon Marchi via Gdb-patches wrote:
> From: Simon Marchi <simon.marchi@efficios.com>
>
> The test introduced by the following patch would sometimes fail in this
> configuration:
>
> FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=14: next to for loop
>
> The test has multiple threads constantly forking or vforking while the
> main thread keep doing "next"s.
>
> (After writing the commit message, I realized this also fixes a similar
> failure in gdb.threads/forking-threads-plus-breakpoint.exp with the
> native-gdbserver and native-extended-gdbserver boards.)
>
> As stop_all_threads is called, because the main thread finished its
> "next", it inevitably happens at some point that we ask the remote
> target to stop a thread and wait() reports that this thread stopped with
> a fork or vfork event, instead of the SIGSTOP we sent to try to stop it.
>
> While running this test, I attached to GDBserver and stopped at
> linux-low.cc:3626. We can see that the status pulled from the kernel
> for 2742805 is indeed a vfork event:
>
> (gdb) p/x w
> $3 = 0x2057f
> (gdb) p WIFSTOPPED(w)
> $4 = true
> (gdb) p WSTOPSIG(w)
> $5 = 5
> (gdb) p/x (w >> 8) & (PTRACE_EVENT_VFORK << 8)
> $6 = 0x200
>
> However, the statement at line 3626 overrides that:
>
> ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
>
> OURSTATUS becomes "stopped by a SIGTRAP". The information about the
> fork or vfork is lost.
>
> It's then all downhill from there, stop_all_threads eventually asks for
> a thread list update. That thread list includes the child of that
> forgotten fork or vfork, the remote target goes "oh cool, a new process,
> let's attach to it!", when in fact that vfork child's destiny was to be
> detached.
>
> My reverse-engineered understanding of the code around there is that the
> if/else between lines 3562 and 3583 (in the original code) makes sure
> OURSTATUS is always initialized (not "ignore"). Either the details are
> already in event_child->waitstatus (in the case of fork/vfork, for
> example), in which case we just copy event_child->waitstatus to
> ourstatus. Or, if the event is a plain "stopped by a signal" or a
> syscall event, OURSTATUS is set to "stopped", but without a signal
> number. Lines 3601 to 3629 (in the original code) serve to fill in that
> last bit of information.
>
> The problem is that when `w` holds the vfork status, the code wrongfully
> takes this branch, because WSTOPSIG(w) returns SIGTRAP:
>
> else if (current_thread->last_resume_kind == resume_stop
> && WSTOPSIG (w) != SIGSTOP)
>
> The intent of this branch is, for example, when we sent SIGSTOP to try
> to stop a thread, but wait() reports that it stopped with another signal
> (that it must have received from somewhere else simultaneously), say
> SIGWINCH. In that case, we want to report the SIGWINCH. But in our
> fork/vfork case, we don't want to take this branch, as the thread didn't
> really stop because it received a signal. For the non "stopped by a
> signal" and non "syscall signal" cases, we would ideally skip over all
> that snippet that fills in the signal or syscall number.
>
> The fix I propose is to move this snipppet of the else branch of the
> if/else above. In addition to moving the code, the last two "else if"
> branches:
>
> else if (current_thread->last_resume_kind == resume_stop
> && WSTOPSIG (w) != SIGSTOP)
> {
> /* A thread that has been requested to stop by GDB with vCont;t,
> but, it stopped for other reasons. */
> ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
> }
> else if (ourstatus->kind () == TARGET_WAITKIND_STOPPED)
> ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
>
> are changed into a single else:
>
> else
> ourstatus->set_stopped (gdb_signal_from_host (WSTOPSIG (w)));
>
> This is the default path we take if:
>
> - W is not a syscall status
> - W does not represent a SIGSTOP that have sent to stop the thread and
> therefore want to suppress it
>
> Change-Id: If2dc1f0537a549c293f7fa3c53efd00e3e194e79

This is OK. Thanks.