This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 5/7] Add thread_db_notice_clone to gdbserver
- From: Pedro Alves <palves at redhat dot com>
- To: Kevin Buettner <kevinb at redhat dot com>, gdb-patches at sourceware dot org
- Date: Fri, 29 Sep 2017 13:24:42 +0100
- Subject: Re: [PATCH v4 5/7] Add thread_db_notice_clone to gdbserver
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EB1625F795
- References: <20170816092542.6d2deb00@pinnacle.lan> <20170816104143.0af5d91a@pinnacle.lan>
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