From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14427 invoked by alias); 28 Mar 2014 17:35:25 -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 14403 invoked by uid 89); 28 Mar 2014 17:35:23 -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: mtaout25.012.net.il Received: from mtaout25.012.net.il (HELO mtaout25.012.net.il) (80.179.55.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Mar 2014 17:35:20 +0000 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N3500D00POW5T00@mtaout25.012.net.il> for gdb-patches@sourceware.org; Fri, 28 Mar 2014 20:33:58 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N35007SHQ4LY560@mtaout25.012.net.il>; Fri, 28 Mar 2014 20:33:57 +0300 (IDT) Date: Fri, 28 Mar 2014 17:35:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <53358C37.9050907@redhat.com> To: Pedro Alves Cc: brobecker@adacore.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83a9cafcpz.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> X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00667.txt.bz2 > Date: Fri, 28 Mar 2014 14:50:31 +0000 > From: Pedro Alves > CC: Joel Brobecker , gdb-patches@sourceware.org > > On 03/26/2014 06:49 PM, Eli Zaretskii wrote: > > This describes the results of my looking into this issue, given the > > comments and suggestions by Joel and Pedro. Sorry about the length. > > > >> I didn't mean to change the behavior - only hide the warning. > >> In this case, if it is normal that we can't suspend the thread, > >> then there is no point in warning (scaring) the user about it. > >> I would only generate a warning if something abnormal that we should > >> fix occured. > > > > The patch near the end of this message indeed includes code to ignore > > the warning in these cases. > > > >> I see that the GetThreadContext call (do_windows_fetch_inferior_registers) > >> doesn't check for errors (I think it should (*)). It'd be interesting to know whether gdb can > >> actually read the registers off of this thread, and if so, what's the > >> thread's backtrace like. > > > > I added CHECK to that call to GetThreadContext. It never produced a > > warning in all my testing, and it looks like we do succeed to get the > > registers. At least the registers of 2 such threads show different > > contents, and the EIP value is consistent with what "info threads" > > displays. > > It isn't clear to me whether you're saying that you saw the > SuspendThread failure trigger in all your new testing, so that > we'd know for sure whether GetThreadContext suceeds in that case, > or whether it might have been that you just were "lucky" enough > to not trigger the SuspendThread failure issue. The former. > Does your patch fix the test case in PR14018, without producing > a CHECK warning from the new CHECK in GetThreadContext you've > added? Yes. > > I can show you 2 typical examples. This is from Emacs, where the > > application has 3 threads, and one more is started by the debugger. > > The rest, threads 5 and 6 in these examples, are those mysterious > > threads we are talking about. > > > > (gdb) info threads > > Id Target Id Frame > > 6 Thread 15492.0x1f28 0x77a41f46 in ntdll!ZwWaitForWorkViaWorkerFactory > > () from C:\Windows\system32\ntdll.dll > > 5 Thread 15492.0x73c0 0x77a41f46 in ntdll!ZwWaitForWorkViaWorkerFactory > > () from C:\Windows\system32\ntdll.dll > > 4 Thread 15492.0x2300 0x75ac78d7 in USER32!DispatchMessageW () > > from C:\Windows\syswow64\user32.dll > > 3 Thread 15492.0x1860 0x77a3fd91 in ntdll!ZwDelayExecution () > > from C:\Windows\system32\ntdll.dll > > 2 Thread 15492.0x2410 0x77a4015d in ntdll!ZwWaitForMultipleObjects () > > from C:\Windows\system32\ntdll.dll > > * 1 Thread 15492.0x44a0 cleanup_vector (vector=0x62daeb0) at alloc.c:2917 > > > > (gdb) info threads > > Id Target Id Frame > > 6 Thread 15492.0x1f28 0x77a3f8d1 in ntdll!ZwWaitForSingleObject () > > from C:\Windows\system32\ntdll.dll > > 5 Thread 15492.0x73c0 0x77a72880 in ntdll!RtlFillMemoryUlong () > > from C:\Windows\system32\ntdll.dll > > 4 Thread 15492.0x2300 0x75ac78d7 in USER32!DispatchMessageW () > > from C:\Windows\syswow64\user32.dll > > 3 Thread 15492.0x1860 0x77a3fd91 in ntdll!ZwDelayExecution () > > from C:\Windows\system32\ntdll.dll > > 2 Thread 15492.0x2410 0x77a4015d in ntdll!ZwWaitForMultipleObjects () > > from C:\Windows\system32\ntdll.dll > > * 1 Thread 15492.0x44a0 cleanup_vector (vector=0x388ca58) at alloc.c:2917 > > > > The first display is what I usually see: several (I've seen up to 4) > > threads waiting inside ZwWaitForWorkViaWorkerFactory. But sometimes > > they do perform some work, as can be seen from the second display. > > OK, but these don't appear to be backtraces taken right after > SuspendThread failed. Yes, they are after SuspendThread failed. > Why bother calling SetThreadContext at all if we just killed > the process? See my other mail and Joel's response. > > Finally, here's the full patch. I hope this research answered all the > > questions, and we can now get the patch in. > > I'm not sure it did, but in any case the patch looks good to me. If that's an approval, I will happily commit the changes. > Sounds like GDBserver might have this problem too. If there's an easy way to verify that, without having 2 systems talking via some communications line, please tell how, and I will try that. Thanks.