[llvm] 206cafb - Follow up to 9fd9d56dc6b, avoid a memory leak

Jeremy Morse via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 2 08:01:22 PST 2022


Author: Jeremy Morse
Date: 2022-02-02T16:01:11Z
New Revision: 206cafb680cea0741f8c7b276351db516ff27f81

URL: https://github.com/llvm/llvm-project/commit/206cafb680cea0741f8c7b276351db516ff27f81
DIFF: https://github.com/llvm/llvm-project/commit/206cafb680cea0741f8c7b276351db516ff27f81.diff

LOG: Follow up to 9fd9d56dc6b, avoid a memory leak

Gaps in the basic block number range (from blocks being deleted or folded)
get block-value-tables allocated but never ejected, leading to a memory
leak, currently tripping up the asan buildbots. Fix this up by manually
freeing that memory.

As suggested elsewhere, if these things were owned by a unique_ptr then
cleanup would happen automagically. D118774 should eliminate the need for
this dance.

Added: 
    

Modified: 
    llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp

Removed: 
    


################################################################################
diff  --git a/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp b/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
index 55e515417ecb..3b4d717c9ab4 100644
--- a/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
+++ b/llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp
@@ -3032,6 +3032,16 @@ bool InstrRefBasedLDV::depthFirstVLocAndEmit(
     if (MOutLocs[MBB->getNumber()])
       EjectBlock(*MBB);
 
+  // Finally, there might have been gaps in the block numbering, from dead
+  // blocks being deleted or folded. In those scenarios, we might allocate a
+  // block-table that's never ejected, meaning we have to free it at the end.
+  for (unsigned int I = 0; I < MaxNumBlocks; ++I) {
+    if (MInLocs[I]) {
+      delete[] MInLocs[I];
+      delete[] MOutLocs[I];
+    }
+  }
+
   return emitTransfers(AllVarsNumbering);
 }
 


        


More information about the llvm-commits mailing list