From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24255 invoked by alias); 27 Mar 2014 17:41: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 24246 invoked by uid 89); 27 Mar 2014 17:41:44 -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: mtaout29.012.net.il Received: from mtaout29.012.net.il (HELO mtaout29.012.net.il) (80.179.55.185) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Mar 2014 17:41:43 +0000 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N3300O00VTERG00@mtaout29.012.net.il> for gdb-patches@sourceware.org; Thu, 27 Mar 2014 19:44:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3300L0FVXW4G40@mtaout29.012.net.il>; Thu, 27 Mar 2014 19:44:20 +0200 (IST) Date: Thu, 27 Mar 2014 17:41:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <20140327125646.GA4030@adacore.com> To: Joel Brobecker Cc: palves@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83k3bfy1ws.fsf@gnu.org> References: <83txawa9wk.fsf@gnu.org> <20140318161608.GD4282@adacore.com> <83pplja2h9.fsf@gnu.org> <20140318165413.GE4282@adacore.com> <834n2kztfw.fsf@gnu.org> <20140327125646.GA4030@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00638.txt.bz2 > Date: Thu, 27 Mar 2014 05:56:46 -0700 > From: Joel Brobecker > Cc: Pedro Alves , gdb-patches@sourceware.org > > > My theory is that we get those Access Denied (winerr = 5) errors when > > we try to suspend these threads when they are about to exit. That's > > because I normally see a "Thread exited" message immediately after the > > warning with the error code. However, testing whether the thread > > exited, and avoiding the SuspendThread call if it did, didn't stop the > > warnings, so I guess the issue is more subtle. E.g., it could be that > > during the final stages of thread shutdown, the thread runs some > > privileged code or something, which precludes suspension. > > Perhaps a simpler theory is that these threads are typically > short-lived, and so you'd be always be seeing their exit soon > after they are created. They live for several minutes, so not so short-lived. > > In addition, I tried to solve warnings like these: > > > > error return windows-nat.c:1306 was 5 > > [Thread 15492.0x68a0 exited with code 0] > > (gdb) q > > A debugging session is active. > > > > Inferior 1 [process 15492] will be killed. > > > > Quit anyway? (y or n) y > > error return windows-nat.c:1306 was 5 > > Yay! :) > > > These come from SetThreadContext in windows_continue. The second > > occurrence is because we already killed the inferior by calling > > TerminateProcess, so its threads begin to shut down, and trying to set > > their context might indeed fail. The first warning is about one of > > those same threads, and again happens just before the thread exit is > > announced. > > > > My solution, which you can see below, is (a) pass an additional > > parameter to windows_continue telling it that the inferior was killed, > > in which case it doesn't bother checking errors from the > > SetThreadContext call; and (b) check if the thread already exited, and > > if so, avoid calling SetThreadContext on it. This completely avoids > > the warning when killing the inferior, and removes most (but not all) > > of the warnings for the other threads. > > I am missing the command that caused the first error. From what you > are saying, was it "kill"? No, it was "continue", which caused the inferior to run until a breakpoint, at which point I typed "q". The thread exit event happened while the inferior was running. > it'd be interesting to understand why we send a TerminateProcess > first, and then try to SetThreadContext later on. It does not seem > to make sense. That happens because windows_kill_inferior does this: static void windows_kill_inferior (struct target_ops *ops) { CHECK (TerminateProcess (current_process_handle, 0)); for (;;) { if (!windows_continue (DBG_CONTINUE, -1, 1)) break; if (!WaitForDebugEvent (¤t_event, INFINITE)) break; if (current_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT) break; } target_mourn_inferior (); /* Or just windows_mourn_inferior? */ } IOW, we resume the inferior (perhaps to collect all the debug events?). > Perhaps one way to address the problem more globally is to have > a version of the CHECK macro that ignores access-denied errors, > and use this one on operations where we know we might get that > error? We only have one or 2 places for that right now, so I wouldn't think a separate macro is justified. > > Finally, here's the full patch. I hope this research answered all the > > questions, and we can now get the patch in. > > I'm good with the first half of the patch that handles SuspendThread > more gracefully. For the additional argument to windows_continue, > I propose we handle that as a separate patch. It's the right thing > to do procedurally anyway, and it'll give us a chance to investigate > more without holding the first half up. Given what I told above, what additional investigations are needed? Note that the second part is not entirely separate: those phantom threads hit the problem with SetThreadContext as well, and checking whether the thread already exited does let through fewer of those warnings.