From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54584 invoked by alias); 10 May 2018 21:02: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 54491 invoked by uid 89); 10 May 2018 21:02:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 May 2018 21:02:42 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w4AL2agN016246 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 10 May 2018 17:02:40 -0400 Received: by simark.ca (Postfix, from userid 112) id DF26D1F215; Thu, 10 May 2018 17:02:35 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id A8F7E1E56F; Thu, 10 May 2018 17:02:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 May 2018 21:10:00 -0000 From: Simon Marchi To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFC] (windows) GDB/MI crash when using "-list-thread-groups --available" In-Reply-To: <1525978704-70543-1-git-send-email-brobecker@adacore.com> References: <1525978704-70543-1-git-send-email-brobecker@adacore.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 10 May 2018 21:02:36 +0000 X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00268.txt.bz2 On 2018-05-10 14:58, Joel Brobecker wrote: > Hello, > > On Windows, using the "-list-thread-groups --available" GDB/MI command > before an inferior is being debugged: > > % gdb -q -i=mi > =thread-group-added,id="i1" > =cmd-param-changed,param="auto-load safe-path",value="/" > (gdb) > -list-thread-groups --available > Segmentation fault > > Ooops! > > The SEGV happens because the -list-thread-groups --available command > triggers a windows_nat_target::xfer_partial call for a > TARGET_OBJECT_OSDATA > object. Until a program is being debugged, the target_ops layer that > gets the call is the Windows "native" layer. Except for a couple of > specific objects (TARGET_OBJECT_MEMORY and TARGET_OBJECT_LIBRARIES), > this layer's xfer_partial method delegates the xfer of other objects > to the target beneath: > > default: > return beneath->xfer_partial (object, annex, > readbuf, writebuf, offset, len, > xfered_len); > > Unfortunately, there is no "beneath layer" in this case, so > beneath is NULL and dereferencing it leads to the SEGV. > > This patch fixes the issue by checking beneath before trying > to delegate the request. But I am wondering whether this is > the right place to fix this issue, or whether we should expect > BENEATH to never be NULL. Ideas? So when an inferior is started, "-list-thread-groups --available" works correctly on Windows? What is the target beneath then, which provides the list of available processes on Windows? Looking at how it works on Linux, it's the process stratum, inf_ptrace_target, that answers this request. On Windows, shouldn't windows_nat_target answer this request? After all, it's the responsibility of windows_nat_target to communicate with the Windows OS to debug processes natively on it. > Also, The testcase I am proposing fails on the -list-thread-groups test > when run on GNU/Linux because, on that platform, the command returns > more output than the expect buffer can handle, resulting in an > UNRESOLVED > status. How does one usually handle this? The only why I can think of > is a loop of gdb_test_multiple... Other ideas? What's the difference between the new test case and gdb.mi/list-thread-groups-available.exp? In that one too, -list-thread-groups --available is executed with no inferior started. It also uses mi_gdb_test though, so it probably hits the same limitation. As a quick and dirty hack, is it possible to just increase temporarily the size of the buffer to something that will surely be large enough? Otherwise, using gdb_test_multiple or maybe gdb_expect to consume the output little by little sounds good. Simon