aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-gdb-readline.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2018-08-10 10:16:32 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2018-08-14 13:38:51 +0100
commit67943c005fafa4397535766787b4fbda338ac07d (patch)
tree7a1b746a9081185e5b1b99d27b3750fa421571d8 /gdb/python/py-gdb-readline.c
parent2a50366ded329bfb39d387253450c9d5302c3503 (diff)
downloadbinutils-67943c005fafa4397535766787b4fbda338ac07d.zip
binutils-67943c005fafa4397535766787b4fbda338ac07d.tar.gz
binutils-67943c005fafa4397535766787b4fbda338ac07d.tar.bz2
gdb: Fix instability in thread groups test
In the test script gdb.mi/list-thread-groups-available.exp we ask GDB to list all thread groups, and match the output against a regexp. Occasionally, I would see this test fail. The expected output is a list of entries, each entry looking roughly like this: {id="<DECIMAL>",type="process",description="<STRING>", user="<STRING>",cores=["<DECIMAL>","<DECIMAL>",...]} All the fields after 'id' and 'type' are optional, and the 'cores' list can contain 1 or more "<DECIMAL>" entries. On my machine (Running Fedora 27, kernel 4.17.3-100.fc27.x86_64) usually the 'description' is a non-empty string, and the 'cores' list has at least one entry in it. But sometimes, very rarely, I'll see an entry in the process group list where the 'description' is an empty string, the 'user' is the string "?", and the 'cores' list is empty. Such an entry looks like this: {id="19863",type="process",description="",user="?",cores=[]} I believe that this is caused by the process exiting while GDB is scanning /proc for process information. The current code in gdb/nat/linux-osdata.c is not (I think) resilient against exiting processes. This commit adjusts the regex that matches the 'cores' list so that an empty list is acceptable, with this patch in place the test script gdb.mi/list-thread-groups-available.exp never fails for me now. I've only adjusted the cores regexp for the occasion when we have GDB read information about all processes, its only in this case that we might encounter an exiting process. When we read information about two known PIDs, that we know will not exit for the duration of the test, we require that the core list be non-empty. gdb/testsuite/ChangeLog: * gdb.mi/list-thread-groups-available.exp: Update test regexp.
Diffstat (limited to 'gdb/python/py-gdb-readline.c')
0 files changed, 0 insertions, 0 deletions