llvmorg-github-actions[bot] wrote:

<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-lldb

Author: aokblast

<details>
<summary>Changes</summary>

IRMemoryMap estimates a free address range using memory information. However, 
the memory returns by AllocateMemory can overlap with the ranges reported by 
MemoryInfo (internally backed by PT_VM_ENTRY), because the kernel is unaware of 
allocations made during the probing process.

As a result, two allocatios may silently insert duplicate key for different 
objects, leading to intermittent test failure. The issue is nodeterministic 
because it depends on the underlying malloc implementation and ASLR.

Fix this by detecting overlapping allocations after AllocateMemory. If an 
overlap is found, fall back to the address-guessing path, which perform the 
necessary overlap checks before committing the allocation.

Also, return and print  message in IRInterpreter in unsecessful allocation.

---
Full diff: https://github.com/llvm/llvm-project/pull/208876.diff


2 Files Affected:

- (modified) lldb/source/Expression/IRInterpreter.cpp (+6-1) 
- (modified) lldb/source/Expression/IRMemoryMap.cpp (+20-1) 


``````````diff
diff --git a/lldb/source/Expression/IRInterpreter.cpp 
b/lldb/source/Expression/IRInterpreter.cpp
index 69e7d0b327803..cb5151f6823a1 100644
--- a/lldb/source/Expression/IRInterpreter.cpp
+++ b/lldb/source/Expression/IRInterpreter.cpp
@@ -722,6 +722,7 @@ bool IRInterpreter::Interpret(llvm::Module &module, 
llvm::Function &function,
   if (frame.m_frame_process_address == LLDB_INVALID_ADDRESS) {
     error =
         lldb_private::Status::FromErrorString("Couldn't allocate stack frame");
+    return false;
   }
 
   int arg_index = 0;
@@ -737,7 +738,11 @@ bool IRInterpreter::Interpret(llvm::Module &module, 
llvm::Function &function,
 
     lldb::addr_t ptr = args[arg_index];
 
-    frame.MakeArgument(&*ai, ptr);
+    if (!frame.MakeArgument(&*ai, ptr)) {
+      error = lldb_private::Status::FromErrorString(
+          "Couldn't write an argument into the interpreter's stack frame");
+      return false;
+    }
   }
 
   frame.Jump(&function.front());
diff --git a/lldb/source/Expression/IRMemoryMap.cpp 
b/lldb/source/Expression/IRMemoryMap.cpp
index fd46a48930bd4..c9146c648d611 100644
--- a/lldb/source/Expression/IRMemoryMap.cpp
+++ b/lldb/source/Expression/IRMemoryMap.cpp
@@ -74,8 +74,16 @@ lldb::addr_t IRMemoryMap::FindSpace(size_t size) {
 
     if (!alloc_error.Success())
       return LLDB_INVALID_ADDRESS;
-    else
+
+    // The process knows nothing about host-only allocations handed out by the
+    // guessing algorithm below, so the address it returned may collide with
+    // one of them.  Give the memory back and fall through to hunting for a
+    // free range above the existing allocations instead.
+    if (!IntersectsAllocation(ret, size))
       return ret;
+
+    process_sp->DeallocateMemory(ret);
+    ret = LLDB_INVALID_ADDRESS;
   }
 
   // At this point we know that we need to hunt.
@@ -419,6 +427,17 @@ IRMemoryMap::Malloc(size_t size, uint8_t alignment, 
uint32_t permissions,
   lldb::addr_t mask = alignment - 1;
   aligned_address = (allocation_address + mask) & (~mask);
 
+  // A collision here means FindSpace or the process allocator returned an
+  // address that overlaps a live allocation.  Registering it anyway would
+  // silently fail (duplicate map key) or alias another allocation's memory,
+  // corrupting expression state in hard-to-debug ways.  Fail loudly instead.
+  if (IntersectsAllocation(allocation_address, allocation_size)) {
+    return llvm::createStringError(llvm::inconvertibleErrorCode(),
+                                   "Couldn't malloc: allocation at 0x%" PRIx64
+                                   " collides with an existing allocation",
+                                   allocation_address);
+  }
+
   m_allocations.emplace(
       std::piecewise_construct, std::forward_as_tuple(aligned_address),
       std::forward_as_tuple(allocation_address, aligned_address,

``````````

</details>


https://github.com/llvm/llvm-project/pull/208876
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to