From patchwork Mon Mar 17 19:43:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eli Zaretskii X-Patchwork-Id: 129 Return-Path: X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx22.g.dreamhost.com (caibbdcaabij.dreamhost.com [208.113.200.189]) by wilcox.dreamhost.com (Postfix) with ESMTP id 16C22360084 for ; Mon, 17 Mar 2014 12:43:35 -0700 (PDT) Received: by homiemail-mx22.g.dreamhost.com (Postfix, from userid 14314964) id BBCE34FB6673; Mon, 17 Mar 2014 12:43:34 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx22.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx22.g.dreamhost.com (Postfix) with ESMTPS id 978ED4FB6642 for ; Mon, 17 Mar 2014 12:43:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:subject:to:reply-to:message-id; q= dns; s=default; b=GyADE1zXtMfqhCDw8HlFCWDhBlvNkgCVPaznS6x5wld3pj RlH2nq+xUt62x1sjJLP28l7KwTY63ScXhLlBT67qRQU3NiS79uoRr1QI1Kd+tsM5 QR0yIMDI7wwy47t0o0SHqUj+le29TsW6k3strQFjA9REp/u+S/SsC0D833g4k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:subject:to:reply-to:message-id; s= default; bh=IqVu1BhIzuPckrX82+WNq/hxJ2w=; b=mJ9XCI90CoUTZxgu4Jtx B5cDhPnnoK7iOZal69jPCOVX21mWfL5/b4I7vkcncbZi+7EQNpkWYxaSYo9YFUL3 4TgIqLy+LizhXwAmGvSqyjapgmNJ6o2ZRhb724XXpC+VUd9LIaylQwqyB4ClKypY faR4EB92ngGbgMo/cNKgG04= Received: (qmail 4827 invoked by alias); 17 Mar 2014 19:43:33 -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 4817 invoked by uid 89); 17 Mar 2014 19:43:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL, BAYES_00, SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout27.012.net.il Received: from mtaout27.012.net.il (HELO mtaout27.012.net.il) (80.179.55.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Mar 2014 19:43:30 +0000 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N2L00G00IL3NK00@mtaout27.012.net.il> for gdb-patches@sourceware.org; Mon, 17 Mar 2014 21:40:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2L0085EINSTL70@mtaout27.012.net.il> for gdb-patches@sourceware.org; Mon, 17 Mar 2014 21:40:40 +0200 (IST) Date: Mon, 17 Mar 2014 21:43:23 +0200 From: Eli Zaretskii Subject: [PATCH] Fix "PC register is not available" issue To: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83txawa9wk.fsf@gnu.org> X-IsSubscribed: yes X-DH-Original-To: gdb@patchwork.siddhesh.in This problem was raised and mentioned several times over the last few years. It was discussed here in the thread which started with this message: https://sourceware.org/ml/gdb-patches/2013-06/msg00237.html In the ensuing discussion, there was a consensus that these failures shouldn't be fatal, and perhaps we should even ignore them entirely. The most annoying problem with this is that after the message about failure to suspend a thread, there's another message: warning: SuspendThread (tid=0x720) failed. (winerr 5) PC register is not available <<<<<<<<<<<<<<<<<<<<<<<<< and the debug session becomes useless after that: the debuggee stops, and you cannot continue it. You can only examine memory. A very similar, perhaps the same, problem is described here: https://sourceware.org/bugzilla/show_bug.cgi?id=14018 There you can find a short test program that demonstrates the issue, and some analysis. After hitting this problem myself many times, I came to the same conclusion: namely, that GDB is trying to suspend a thread for which it doesn't have the necessary privileges. My hypothesis is that those are the threads that Windows starts in the context of the process being debugged, perhaps for the purposes of handling some debug events. (I can see the "New thread" messages from time to time, although I know for certain that the inferior didn't start any application threads.) So I came up with the patch below. The idea is that setting th->suspended to -1 just signals to GDB that the thread isn't suspended, and shouldn't be resumed; otherwise, we simply ignore the failure to suspend the thread, although the warning is still printed. I am running with this patch for almost a month, and the dreaded "PC register is not available" message didn't appear even once. No more botched debugging sessions! The test program in PR/14018 also runs indefinitely until interrupted, instead of stopping. So I suggest to install this. OK? Should I also close the Bugzilla PR? --- gdb/windows-nat.c~0 2014-02-06 04:21:29.000000000 +0200 +++ gdb/windows-nat.c 2014-02-26 22:27:10.225625000 +0200 @@ -313,9 +313,10 @@ thread_rec (DWORD id, int get_context) warning (_("SuspendThread (tid=0x%x) failed." " (winerr %u)"), (unsigned) id, (unsigned) err); - return NULL; + th->suspended = -1; } - th->suspended = 1; + else + th->suspended = 1; } else if (get_context < 0) th->suspended = -1;