aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.dap/modules.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-08-14 21:53:57 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-08-16 15:03:56 +0100
commita345d14fa65c2b69f2ba3abac8847b1c6a4dc656 (patch)
treec1cc8ce495d73df2da1850ffad09373587a90f9c /gdb/testsuite/gdb.dap/modules.c
parent05e1cac2496f842f70744dc5210fb3072ef32f3a (diff)
downloadbinutils-a345d14fa65c2b69f2ba3abac8847b1c6a4dc656.zip
binutils-a345d14fa65c2b69f2ba3abac8847b1c6a4dc656.tar.gz
binutils-a345d14fa65c2b69f2ba3abac8847b1c6a4dc656.tar.bz2
gdb/testsuite: fix race condition in gdb.python/py-thread-exited.exp
I ran into a test failure on gdb.python/py-thread-exited.c. The test creates two threads and then catches the thread exits in Python. The test expects the threads to exit in a specific order. As the test is currently written, it is _likely_, but not guaranteed, that the threads will exit in the same order they are created, which is what the test expects. When running on a loaded system I ran into a case where the threads exited in the reverse creation order, which caused the test to fail. I could fix this by having the .exp file not care about the thread order, or by changing the C file to force the order. I chose the later, and added a pthread_barrier_t to ensure the threads exit in the correct order. There should be no change in what is tested after this commit.
Diffstat (limited to 'gdb/testsuite/gdb.dap/modules.c')
0 files changed, 0 insertions, 0 deletions