From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@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 19:43:00 -0000 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-SW-Source: 2014-03/txt/msg00397.txt.bz2 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;