This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] (windows) GDB/MI crash when using "-list-thread-groups --available"
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