Re: [PATCH v4 5/7] Add thread_db_notice_clone to gdbserver

[Pedro Alves <palves@redhat.com>]

On 08/16/2017 06:41 PM, Kevin Buettner wrote:
> While working on a patch for fetching a thread handle in gdbserver, I
> ran into a circumstance in which tests in gdb.mi/mi-nsmoribund.exp
> would occasionally fail.  Over a large enough number of runs, it would
> fail roughly 2% of the time.
> 
> That thread handle patch caused find_one_thread() to be called on
> every stop.  find_one_thread() calls td_ta_map_lwp2thr() which, in
> turn, can cause ps_get_thread_area() to be called.
> ps_get_thread_area() makes a call to ptrace() for getting the thread
> area address.  If this should happen when the thread is not stopped,
> the call to ptrace will return error which in turn propogates back to
> find_one_thread().  find_one_thread() calls error() in this instance
> which causes the program to die.
> 
> This patch causes find_one_thread() to be called upon reciept of a
> clone event.  Since the clone is stopped, the circumstances described
> above cannot occur.
> 

FYI, issues like the described above still happened with the
patch as it was.  While both parent/child are stopped, we
weren't making sure that one of parent/child is the
current thread.  That lead to libthread_db -> proc-service
trying to access memory from a running or non-existing thread.

For me that resulted in occasional
gdb.threads/multi-create-ns-info-thr.exp failures.

The gdbserver buildslaves have been reporting the same
regression too, e.g.:
  https://sourceware.org/ml/gdb-testers/2017-q3/msg05653.html

Should be fixed now, with:
 https://sourceware.org/ml/gdb-patches/2017-09/msg00903.html
 https://sourceware.org/ml/gdb-patches/2017-09/msg00904.html

Thanks,
Pedro Alves