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

[Pedro Alves <pedro@palves.net>]

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.