forked from OSchip/llvm-project
1432b9780b
the collection lock before we iterate over the owners calling ShouldStop. BreakpointSite::ShouldStop can do a lot of work, and might by chance hit the same breakpoint site again on another thread. So instead of holding the site's owners lock while iterating over them calling ShouldStop, I make a local copy of the list, drop the lock and then iterate over the copy calling BreakpointLocation::ShouldStop. It's actually quite difficult to make this cause problems because usually all the action happens on the private state thread, and the lock is recursive. I have a report where some code hit the ASAN error breakpoint, went to compile the ASAN error gathering expression, in the course of compiling that we went to fetch the ObjC runtime data, but the state of the program was such that the ObjC runtime grubbing function triggered an ASAN error and we were executing that function on another thread. I couldn't figure out a way to reproduce that situation in a test. But this is an NFC change anyway, it just makes the locking strategy more narrowly focused. <rdar://problem/49074093> llvm-svn: 357141 |
||
|---|---|---|
| .. | ||
| API | ||
| Breakpoint | ||
| Commands | ||
| Core | ||
| DataFormatters | ||
| Expression | ||
| Host | ||
| Initialization | ||
| Interpreter | ||
| Plugins | ||
| Symbol | ||
| Target | ||
| Utility | ||
| CMakeLists.txt | ||
| lldb.cpp | ||