Author: jimingham Date: 2025-05-02T11:51:21-07:00 New Revision: 0ddcd209ddc8956eb52d642937a4397c6b08449c
URL: https://github.com/llvm/llvm-project/commit/0ddcd209ddc8956eb52d642937a4397c6b08449c DIFF: https://github.com/llvm/llvm-project/commit/0ddcd209ddc8956eb52d642937a4397c6b08449c.diff LOG: Don't hold the Target's ModuleListLock over running LoadScriptingResourceInTarget (#138216) That calls an unknown amount of Python code, and can do quite a bit of work - especially if people do things like launch scripted processes in this script affordance. Doing that while holding a major lock like the ModuleList lock is asking for trouble. I tried to make a test that would actually stall without this, but I couldn't come up with anything that reliably failed. You always have to get pretty unlucky. Added: Modified: lldb/source/Core/ModuleList.cpp Removed: ################################################################################ diff --git a/lldb/source/Core/ModuleList.cpp b/lldb/source/Core/ModuleList.cpp index 6052cc151744d..d5ddf6e846112 100644 --- a/lldb/source/Core/ModuleList.cpp +++ b/lldb/source/Core/ModuleList.cpp @@ -1046,8 +1046,14 @@ bool ModuleList::LoadScriptingResourcesInTarget(Target *target, bool continue_on_error) { if (!target) return false; - std::lock_guard<std::recursive_mutex> guard(m_modules_mutex); - for (auto module : m_modules) { + m_modules_mutex.lock(); + // Don't hold the module list mutex while loading the scripting resources, + // The initializer might do any amount of work, and having that happen while + // the module list is held is asking for A/B locking problems. + const ModuleList tmp_module_list(*this); + m_modules_mutex.unlock(); + + for (auto module : tmp_module_list.ModulesNoLocking()) { if (module) { Status error; if (!module->LoadScriptingResourceInTarget(target, error, _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
