From patchwork Thu Mar 26 13:32:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 5827 Received: (qmail 46959 invoked by alias); 26 Mar 2015 13:32:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 46944 invoked by uid 89); 26 Mar 2015 13:32:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 26 Mar 2015 13:32:29 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id EE5C0AD020 for ; Thu, 26 Mar 2015 13:32:27 +0000 (UTC) Received: from brno.lan (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2QDWQPc023694 for ; Thu, 26 Mar 2015 09:32:27 -0400 From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH] linux_nat.c: Mark new thread running even if momentarily pausing Date: Thu, 26 Mar 2015 13:32:26 +0000 Message-Id: <1427376746-31596-1-git-send-email-palves@redhat.com> My all-stop-on-top-of-non-stop series manages to trip on a bug in the linux-nat.c backend while running the testsuite. If a thread is discovered while threads are being momentarily paused (without the core's intervention), the thread ends up stuck in THREAD_STOPPED state, even though from the user's perspective, the thread is running even while it is paused. From inspection, in the current sources, this can happen if we call stop_and_resume_callback, though there's no way to test that with current Linux kernels. (While trying to come up with test to exercise this, I stumbled on: https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html ... which does include a non-trivial test, so I think I can still claim I come out net positive. :-) ) Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-03-26 Pedro Alves * linux-nat.c (linux_handle_extended_wait): Always call set_running. --- gdb/linux-nat.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c index 0376299..04707dc 100644 --- a/gdb/linux-nat.c +++ b/gdb/linux-nat.c @@ -2109,9 +2109,12 @@ linux_handle_extended_wait (struct lwp_info *lp, int status, add_thread (new_lp->ptid); } + /* Even if we're stopping the thread for some reason + internal to this module, from the user/frontend's + perspective, this new thread is running. */ + set_running (new_lp->ptid, 1); if (!stopping) { - set_running (new_lp->ptid, 1); set_executing (new_lp->ptid, 1); /* thread_db_attach_lwp -> lin_lwp_attach_lwp forced resume_stop. */