[Support] Fix memory leak induced by sys::RemoveFileOnSignal

[aganea]

Before this PR, FilesToRemove was constructed but never deleted.

[llvmbot]

@llvm/pr-subscribers-platform-windows

@llvm/pr-subscribers-llvm-support

Author: Alexandre Ganea (aganea)

Changes

Before this PR, FilesToRemove was constructed but never deleted.

---

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

1 Files Affected:

• (modified) llvm/lib/Support/Windows/Signals.inc (+6-1)

diff --git a/llvm/lib/Support/Windows/Signals.inc b/llvm/lib/Support/Windows/Signals.inc
index dad0fa3066868..db6d2eeb4169c 100644
--- a/llvm/lib/Support/Windows/Signals.inc
+++ b/llvm/lib/Support/Windows/Signals.inc
@@ -421,8 +421,13 @@ bool sys::RemoveFileOnSignal(StringRef Filename, std::string *ErrMsg) {
     return true;
   }
 
-  if (FilesToRemove == NULL)
+  if (FilesToRemove == NULL) {
     FilesToRemove = new std::vector<std::string>;
+    std::atexit([]() {
+      delete FilesToRemove;
+      FilesToRemove = NULL;
+    });
+  }
 
   FilesToRemove->push_back(std::string(Filename));
 

[yronglin]

I think we can change FilesToRemove from static std::vector<std::string> *FilesToRemove = NULL; to static std::vector<std::string> FilesToRemove;, and change all pices where FilesToRemove == NULL to FilesToRemove.empty(), What do you think?

[aganea]

I was thinking about that. However if we make it a non-pointer, and it is destroyed during global destruction; if any other subsequent global variable destructor code tries to access FilesToRemove after its destruction, that might crash in unexpected ways. Whereas here, as a pointer, it is clearly set to NULL and we already check if (FilesToRemove != NULL) in all the APIs.

[yronglin]

Hmm, yes, it's may depends on globals destruct order.

[yronglin]

LGTM!