[Lldb-commits] [lldb] [LLDB] Don't cache module sp when Activate() fails. (PR #95586)

[via lldb-commits]

https://github.com/thetruestblue created https://github.com/llvm/llvm-project/pull/95586

Currently, the instrumentation runtime is caching a library the first time it sees it in the module list. However, in some rare cases on Darwin, the cached pre-run unloaded modules are different from the runtime module that is loaded at runtime. This patch removes the cached module if the plugin fails to activate, ensuring that on subsequent calls we don't try to activate using the unloaded cached module.

There are a few related bugs to fix in a follow up: CheckIfRuntimeValid should have a stronger check to ensure the module is loaded and can be activated. Further investigation in UpdateSpecialBinariesFromNewImageInfos calling ModulesDidLoad when the module list may have unloaded modules.

I have not included a test for the following reasons:
1. This is an incredibly rare occurance and is only observed in a specific circumstance on Darwin. It is tied to behavior in the DynamicLoader thai is not commonly encountered.

2. It is difficult to reproduce -- this bug requires precise conditions on darwin and it is unclear how we'd reproduce that in a controlled testing environment.

rdar://128971453


>From db161e5c87eecbd5607f78e7afd00af183aa415c Mon Sep 17 00:00:00 2001
From: Blue Gaston <bgaston2 at apple.com>
Date: Fri, 14 Jun 2024 12:53:27 -0400
Subject: [PATCH] [LLDB] Don't cache module sp when Activate() fails.

Currently, the instrumentation runtime is caching a library the first time it sees it in the module list. However, in some rare cases on Darwin, the cached pre-run unloaded modules are different from the runtime module that is loaded at runtime. This patch removes the cached module if the plugin fails to activate, ensuring that on subsequent calls we don't try to activate using the unloaded cached module.

There are a few related bugs to fix in a follow up: CheckIfRuntimeValid should have a stronger check to ensure the module is loaded and can be activated. Further investigation in UpdateSpecialBinariesFromNewImageInfos calling ModulesDidLoad when the module list may have unloaded modules.

I have not included a test for the following reasons:
1. This is an incredibly rare occurance and is only observed in a specific circumstance on Darwin. It is tied to behavior in the DynamicLoader thai is not commonly encountered.

2. It is difficult to reproduce -- this bug requires precise conditions on darwin and it is unclear how we'd reproduce that in a controlled testing environment.

rdar://128971453
---
 lldb/source/Target/InstrumentationRuntime.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lldb/source/Target/InstrumentationRuntime.cpp b/lldb/source/Target/InstrumentationRuntime.cpp
index 9f22a1be20ccb..94f4ca353d7ef 100644
--- a/lldb/source/Target/InstrumentationRuntime.cpp
+++ b/lldb/source/Target/InstrumentationRuntime.cpp
@@ -60,6 +60,8 @@ void InstrumentationRuntime::ModulesDidLoad(
       if (CheckIfRuntimeIsValid(module_sp)) {
         SetRuntimeModuleSP(module_sp);
         Activate();
+        if (IsActive())
+          SetRuntimeModuleSP({}); // Don't cache module if activation failed.
         return false; // Stop iterating, we're done.
       }
     }