Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Pedro Alves <palves@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [RFC] (windows) GDB/MI crash when using "-list-thread-groups --available"
Date: Wed, 16 May 2018 15:52:00 -0000	[thread overview]
Message-ID: <81952681aacf4123fd897dfa330efd6b@polymtl.ca> (raw)
In-Reply-To: <ba03aa7a-1474-2329-da05-038520f0eae2@redhat.com>

On 2018-05-11 12:45, Pedro Alves wrote:
> After the inferior is started, the Windows target is pushed in the 
> target
> stack, so there will be a target beneath, either the exec target, or 
> the
> dummy target directly.  Either of those returns TARGET_XFER_E_IO for
> this target object.
> 
> The issue here is that before the inferior is started, the
> Windows target is not pushed on the target stack.
> See target_get_osdata.

Ah ok, so the target is used without being pushed?  I didn't know it was 
possible.

>> which provides the list of available processes on Windows?
> 
> I don't think the feature works at all on Windows.  It's probably
> returning an empty list of processes.

But Joel reported that the test case fails due to the expect buffer 
being full, so the list must not be empty...  we'll need clarifications 
from him :)

>> 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.
> 
> I've actually saw that testcase fail before because of this issue.  :-)
> I probably saw it when I was running many test jobs in parallel (thus 
> many
> processes) or something like that.

It should be fairly easy to reproduce, start a few thousands "sleep 100 
&" processes and then run the test case.

>> 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.
> 
> Yeah, the best way to address this is to consume
> output in chunks, with exp_continue.  That fixes it for good.
> See for example:
> 
> commit 11859c310cd6b6fd892337a5ee1d36921e6d08d8
> Author:     Andrew Burgess <andrew.burgess@embecosm.com>
> AuthorDate: Mon Apr 9 00:18:34 2018 +0100
> 
>     gdb/testsuite: Handle targets with lots of registers
> 
> 
> I'd prefer that over increasing buffer sizes.

Of course!

Simon


  reply	other threads:[~2018-05-16 15:46 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
2018-05-11 17:14   ` Pedro Alves
2018-05-16 15:52     ` Simon Marchi [this message]
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=81952681aacf4123fd897dfa330efd6b@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /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