From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93317 invoked by alias); 21 Aug 2015 18:54:36 -0000 Mailing-List: contact gdb-testers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-testers-owner@sourceware.org Received: (qmail 93305 invoked by uid 89); 21 Aug 2015 18:54:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: kwanyin.sergiodj.net Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (176.31.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 21 Aug 2015 18:54:34 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [binutils-gdb] gdbserver: don't pick a random thread if the current thread dies From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Message-Id: Date: Fri, 21 Aug 2015 18:54:00 -0000 X-SW-Source: 2015-q3/txt/msg08796.txt.bz2 *** TEST RESULTS FOR COMMIT f0db101d9897732d6556456e542d12ecf9e12e42 *** Author: Pedro Alves Branch: master Commit: f0db101d9897732d6556456e542d12ecf9e12e42 gdbserver: don't pick a random thread if the current thread dies 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-21 Pedro Alves * 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) : Also set thread_id if the previous general thread is still alive. (process_serial_event) : 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.