From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3871 invoked by alias); 8 Apr 2014 17:54:43 -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 3861 invoked by uid 89); 8 Apr 2014 17:54:43 -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,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Apr 2014 17:54:42 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N3Q00J00498GH00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Tue, 08 Apr 2014 20:54:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3Q00JHB4F34U80@a-mtaout20.012.net.il>; Tue, 08 Apr 2014 20:54:39 +0300 (IDT) Date: Tue, 08 Apr 2014 17:54:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <534433A5.4060006@redhat.com> To: Pedro Alves Cc: brobecker@adacore.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ob0b671j.fsf@gnu.org> References: <83txawa9wk.fsf@gnu.org> <20140318161608.GD4282@adacore.com> <83pplja2h9.fsf@gnu.org> <20140318165413.GE4282@adacore.com> <834n2kztfw.fsf@gnu.org> <53358C37.9050907@redhat.com> <83a9cafcpz.fsf@gnu.org> <5335B619.6040605@redhat.com> <8361myfa6l.fsf@gnu.org> <83ioqucrkw.fsf@gnu.org> <5342DBBC.4090500@redhat.com> <83lhvh6lqi.fsf@gnu.org> <5343DE45.5050707@redhat.com> <53442710.60104@redhat.com> <83sipn6937.fsf@gnu.org> <534433A5.4060006@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00103.txt.bz2 > Date: Tue, 08 Apr 2014 18:36:37 +0100 > From: Pedro Alves > CC: brobecker@adacore.com, gdb-patches@sourceware.org > > On 04/08/2014 06:10 PM, Eli Zaretskii wrote: > >> Date: Tue, 08 Apr 2014 17:42:56 +0100 > >> From: Pedro Alves > >> CC: brobecker@adacore.com, gdb-patches@sourceware.org > >> > >> I'd be very curious to see the backtrace you get > >> for the failing thread in your test case (I guess emacs?). > > > > Yes, it's Emacs. Do you mean the backtrace I see when debugging > > natively? > > Yes, but you'll need to use the patch I attached, not yours. > When SuspendThread fails, the warning says which thread failed. > The next "continue", "next", whatever will fail when that > happens (just once, so you can continue debugging as usual > in case you're in the middle of a real debug session). At > that point, "info threads", see which is the gdb thread id > for the thread that failed, switch to it, and get a backtrace, > like I showed in the previous email. I can know which thread's suspension fails even without the patch, because GDB immediately announces its exit. Is the patch just for showing the thread ID, or is it needed for something else? > > Because when debugging Emacs with gdbserver, I cannot > > reproduce the problem with SuspendThread. > > You mean you can't get the warning in GDBserver's console, > or you don't see the "PC register is not available" issue? The former, of course. > Even if the exact test case as in the PR (and as I attached > to the previous email) -- that is, one that continues banging > in a loop until the failure triggers? Or you mean with > emacs? I mean with Emacs. The PR test case is an artificial toy program which also floods the system with threads. I wouldn't consider it a serious real-life use case. > Given I see different backtraces on the same machine in native vs > gdbserver debugging of the same test, and that in gdbserver's case the > failing thread appears to always be further down into thread termination, > it may just be that your machine is a little slower or faster than > mine, and it's harder to stop threads at exactly within the time window > when the SuspendThread problem can trigger. I think multiple cores also come into play here. (My machine is Core i7.) > > OK. But now I'm confused: what is the conclusion from what you saw? > > My conclusion so far is that this happens exactly when we try to > suspend a thread that is already half-dead, no matter who started it, > and that we do need your patch to GDB, and that GDBserver will also > need to the patched. I'm just curious to see your emacs backtrace > to 99% confirm that it's the same thread-exiting scenario, mainly > to put any doubts to rest, for us and for future generations (the > archives). OK, I will try to get that info.