From: Simon Marchi <simon.marchi@polymtl.ca>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] (windows) GDB/MI crash when using "-list-thread-groups --available"
Date: Thu, 10 May 2018 21:10:00 -0000 [thread overview]
Message-ID: <eaa0d8a4e091e97392897d5960df0149@polymtl.ca> (raw)
In-Reply-To: <1525978704-70543-1-git-send-email-brobecker@adacore.com>
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
next prev parent reply other threads:[~2018-05-10 21:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-10 19:12 Joel Brobecker
2018-05-10 21:10 ` Simon Marchi [this message]
2018-05-11 17:14 ` Pedro Alves
2018-05-16 15:52 ` Simon Marchi
2018-05-16 16:44 ` Pedro Alves
2018-06-02 0:59 ` Joel Brobecker
2018-06-02 10:26 ` Pedro Alves
2018-06-04 20:11 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eaa0d8a4e091e97392897d5960df0149@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).