diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-08-14 21:53:57 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-08-16 15:03:56 +0100 |
commit | a345d14fa65c2b69f2ba3abac8847b1c6a4dc656 (patch) | |
tree | c1cc8ce495d73df2da1850ffad09373587a90f9c /gdb/testsuite/gdb.dap/modules.c | |
parent | 05e1cac2496f842f70744dc5210fb3072ef32f3a (diff) | |
download | binutils-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