maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

Fix flakyness in TestWatchpointMultipleThreads 

This addresses the same problem as r264846 (the test not expecting the situation when two thread
hit the watchpoint simultaneously), but for a different test.

llvm-svn: 265294
This commit is contained in:
Pavel Labath 2016-04-04 14:18:21 +00:00
parent ccfe3cb3d6
commit 67f641dd33
2 changed files with 2 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
lldb/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
View File

@ -54,9 +54,6 @@ class HelloWatchLocationTestCase(TestBase):
'stop reason = breakpoint'])
# Now let's set a write-type watchpoint pointed to by 'g_char_ptr'.
# The main.cpp, by design, misbehaves by not following the agreed upon
# protocol of using a mutex while accessing the global pool and by not
# incrmenting the global pool by 2.
self.expect("watchpoint set expression -w write -s 1 -- g_char_ptr", WATCHPOINT_CREATED,
substrs = ['Watchpoint created', 'size = 1', 'type = w'])
# Get a hold of the watchpoint id just created, it is used later on to

6
lldb/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/main.cpp
View File

@ -43,15 +43,13 @@ uint32_t
access_pool (bool flag = false)
{
static std::mutex g_access_mutex;
if (!flag)
g_access_mutex.lock();
g_access_mutex.lock();
char old_val = *g_char_ptr;
if (flag)
do_bad_thing_with_location(g_char_ptr, old_val + 1);
if (!flag)
g_access_mutex.unlock();
g_access_mutex.unlock();
return *g_char_ptr;
}