summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lldbtest_config.py
diff options
context:
space:
mode:
authorPavel Labath <labath@google.com>2016-03-30 08:43:54 +0000
committerPavel Labath <labath@google.com>2016-03-30 08:43:54 +0000
commitec62c0559fa6ccad76ee22e98d8a274995675080 (patch)
tree38b143f96bb2549ac31f003dea8d512ae005592e /lldb/packages/Python/lldbsuite/test/lldbtest_config.py
parent8e06a10d1f68f3d7990295806f1254b2d3ff09fc (diff)
downloadbcm5719-llvm-ec62c0559fa6ccad76ee22e98d8a274995675080.tar.gz
bcm5719-llvm-ec62c0559fa6ccad76ee22e98d8a274995675080.zip
Fix flakyness in TestWatchpointMultipleThreads
Summary: the inferior in the test deliberately does not lock a mutex when accessing the watched variable. The reason for that is unclear as, based on the logs, the original intention of the test was to check whether watchpoints get propagated to newly created threads, which should work fine even with a mutex. Furthermore, in the unlikely event (which I have still observed happening from time to time) that two threads do manage the execute the "critical section" simultaneously, the test will fail, as it is expecting the watchpoint "hit count" to be 1, but in this case it will be 2. Given this, I have simply chose to lock the mutex always, so that we have more predictible behavior. Watchpoints being hit simultaneously is still (and correctly!) tested by TestConcurrentEvents. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18558 llvm-svn: 264846
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/lldbtest_config.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud