From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18723 invoked by alias); 8 Apr 2014 17:36:45 -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 18707 invoked by uid 89); 8 Apr 2014 17:36:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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 ESMTP; Tue, 08 Apr 2014 17:36:43 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s38Hadbc001107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2014 13:36:40 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s38HabCb015914; Tue, 8 Apr 2014 13:36:38 -0400 Message-ID: <534433A5.4060006@redhat.com> Date: Tue, 08 Apr 2014 17:36:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eli Zaretskii CC: brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [PATCH] Fix "PC register is not available" issue 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> In-Reply-To: <83sipn6937.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00102.txt.bz2 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. > 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? 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? As I mentioned in the previous email, you won't get the "PC register not available" issue with GDBserver because GDBserver's thread_rec returns the thread's info structure anyway even if SuspendThread failed, unlike GDB, which returns NULL. If the SuspendThread issue triggers, then the GetThreadContext/SetThreadContext issue should trigger too. But, GDBserver actually currently ignores SetThreadContext fails ...: static void i386_set_thread_context (win32_thread_info *th, DEBUG_EVENT* current_event) { if (debug_registers_changed) { struct i386_debug_reg_state *dr = &debug_reg_state; th->context.Dr0 = dr->dr_mirror[0]; th->context.Dr1 = dr->dr_mirror[1]; th->context.Dr2 = dr->dr_mirror[2]; th->context.Dr3 = dr->dr_mirror[3]; /* th->context.Dr6 = dr->dr_status_mirror; FIXME: should we set dr6 also ?? */ th->context.Dr7 = dr->dr_control_mirror; } SetThreadContext (th->h, &th->context); } 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. >> + /* We get Access Denied (5) when trying to suspend >> + threads that Windows started on behalf of the >> + debuggee, usually when those threads are just >> + about to exit. */ >> + if (err != ERROR_ACCESS_DENIED) >> >> I've shown above that whether it was Windows or the program >> itself that started the threads is irrelevant, it'd be good to >> reword this comment. > > 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). -- Pedro Alves