From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29228 invoked by alias); 18 Mar 2014 16:16:14 -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 29211 invoked by uid 89); 18 Mar 2014 16:16:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 18 Mar 2014 16:16:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8D3B8116610; Tue, 18 Mar 2014 12:16:10 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LQCPQ1TOsat2; Tue, 18 Mar 2014 12:16:10 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4630E116631; Tue, 18 Mar 2014 12:16:10 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B0741E08A0; Tue, 18 Mar 2014 09:16:08 -0700 (PDT) Date: Tue, 18 Mar 2014 16:16:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix "PC register is not available" issue Message-ID: <20140318161608.GD4282@adacore.com> References: <83txawa9wk.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83txawa9wk.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-03/txt/msg00418.txt.bz2 Hi Eli, On Mon, Mar 17, 2014 at 09:43:23PM +0200, Eli Zaretskii wrote: > 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 Thanks for looking into this! > 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; Generally speaking, it seems to make sense to me that we would mark as unsuspended threads that we cannot suspend. But one question that rises from doing that is: how does the rest of GDB handle this thread? In particular, does the thread show up in "info thread" and is the user able to switch to that thread? etc? Certainly, if the current situation is to leave the user stranded, the suggested approach cannot only be an improvement... Another thought I had on your patch is that we might want to limit the warning to situation where the return code is not a permission denied. It would also have been nice to double-check that the thread in question, when the error shows up, is indeed on a system thread unrelated to our program (Eg: the thread created when we try to interrupt the program with ctrl-c or ctrl-break). Not sure if there is a way to determine that, though. I would have looked into that, but I don't have much time this week, and might be equally busy the following 2 weeks, so I didn't want to delay my answer any further. Overall, your patch looks very promising. Sorry I can't be anymore support for the moment. -- Joel