Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdbserver: don't pick a random thread if the current thread dies
Date: Fri, 21 Aug 2015 18:44:00 -0000	[thread overview]
Message-ID: <55D771A0.7040002@redhat.com> (raw)
In-Reply-To: <1438872279-7416-1-git-send-email-palves@redhat.com>

On 08/06/2015 03:44 PM, Pedro Alves wrote:
> In all-stop mode, if the current thread disappears while stopping all
> threads, gdbserver calls set_desired_thread(0) ['0' means "I want the
> continue thread"] which just picks the first thread in the list.
> 
> This looks like a dangerous thing to do.  GDBserver continues
> processing whatever it was doing, but to the wrong thread.  If
> debugging more than one process, we may even pick the wrong process.
> Instead, GDBserver should detect the situation and bail out of
> whatever is was doing.
> 
> The backends used to pay attention to the set 'cont_thread' (the Hc
> thread, used in the old way to resume threads, before vCont), but all
> such 'cont_thread' checks have been eliminated meanwhile.  The
> remaining implicit dependencies that I found on there being a selected
> thread in the backends are in the Ctrl-C handling, which some backends
> use as thread to send a signal to.  Even that seems to me to be better
> handled by always using the first thread in the list or by using the
> signal_pid PID.
> 
> In order to make this a systematic approach, I'm making
> set_desired_thread never fallback to a random thread, and instead end
> up with current_thread == NULL, like already done in non-stop mode.
> Then I updated all callers to handle the situation.
> 
> I stumbled on this while fixing other bugs exposed by
> gdb.threads/fork-plus-threads.exp test.  The problems I saw were fixed
> in a different way, but in any case, I think the potential for
> problems is more or less obvious, and the resulting code looks a bit
> less magical to me.
> 
> Tested on x86-64 Fedora 20, w/ native-extended-gdbserver board.
> 
> gdb/gdbserver/ChangeLog:
> 2015-08-06  Pedro Alves  <palves@redhat.com>
> 
> 	* linux-low.c (wait_for_sigstop): Always switch to no thread
> 	selected if the previously current thread dies.
> 	* lynx-low.c (lynx_request_interrupt): Use the first thread's
> 	process instead of the current thread's.
> 	* remote-utils.c (input_interrupt): Don't check if there's no
> 	current thread.
> 	* server.c (gdb_read_memory, gdb_write_memory): If setting the
> 	current thread to the general thread fails, error out.
> 	(handle_qxfer_auxv, handle_qxfer_libraries)
> 	(handle_qxfer_libraries_svr4, handle_qxfer_siginfo)
> 	(handle_qxfer_spu, handle_qxfer_statictrace, handle_qxfer_fdpic)
> 	(handle_query): Check if there's a thread selected instead of
> 	checking whether there's any thread in the thread list.
> 	(handle_qxfer_threads, handle_qxfer_btrace)
> 	(handle_qxfer_btrace_conf): Don't error out early if there's no
> 	thread in the thread list.
> 	(handle_v_cont, myresume): Don't set the current thread to the
> 	continue thread.
> 	(process_serial_event) <Hg handling>: Also set thread_id if the
> 	previous general thread is still alive.
> 	(process_serial_event) <g/G handling>: If setting the current
> 	thread to the general thread fails, error out.
> 	* spu-low.c (spu_resume, spu_request_interrupt): Use the first
> 	thread's lwp instead of the current thread's.
> 	* target.c (set_desired_thread): If the desired thread was not
> 	found, leave the current thread pointing to NULL.  Return an int
> 	(boolean) indicating success.
> 	* target.h (set_desired_thread): Change return type to int.

I pushed this in.

Thanks,
Pedro Alves


  reply	other threads:[~2015-08-21 18:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 14:54 Pedro Alves
2015-08-21 18:44 ` Pedro Alves [this message]
2015-08-24 14:59 ` Ulrich Weigand
2015-08-24 15:30   ` Pedro Alves
2015-08-24 15:47     ` Pedro Alves
2015-08-24 17:02     ` Pedro Alves
2015-08-24 17:08       ` Ulrich Weigand
2015-08-24 17:13         ` Pedro Alves
2015-08-24 18:39           ` Ulrich Weigand
2015-08-24 19:09             ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55D771A0.7040002@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox