The design of CommandPoolVK is setup so there is a thread_local map that keeps track of a CommandPoolVK (command_pool_vk.cc#L22)). Those CommandPoolVK's are created when a ContextVK is created, then when the thread is killed, the CommandPoolVK should be deallocated.

In the test runner there are hundreds of ContextVK's created on the thread running the unit tests, which means the CommandPoolVK's are never being deallocated. This will eventually result in memory problems.

reproduction

Run impeller unit tests with the following patch, notice that ~CommandPoolVK() is never called.

--- a/impeller/renderer/backend/vulkan/command_pool_vk.cc
+++ b/impeller/renderer/backend/vulkan/command_pool_vk.cc
@@ -70,6 +70,7 @@ void CommandPoolVK::ClearAllPools(const ContextVK* context) {
 
 CommandPoolVK::CommandPoolVK(const ContextVK* context)
     : owner_id_(std::this_thread::get_id()) {
+  FML_LOG(ERROR) << "CommandPoolVK()" << this;
   vk::CommandPoolCreateInfo pool_info;
 
   pool_info.queueFamilyIndex = context->GetGraphicsQueue()->GetIndex().family;
@@ -84,7 +85,9 @@ CommandPoolVK::CommandPoolVK(const ContextVK* context)
   is_valid_ = true;
 }
 
-CommandPoolVK::~CommandPoolVK() = default;
+CommandPoolVK::~CommandPoolVK() {
+  FML_LOG(ERROR) << "~CommandPoolVK() " << this;
+}
 
 bool CommandPoolVK::IsValid() const {
   return is_valid_;

possible solutions

• tweak the test runner to create a new thread for each test that creates a ContextVK
• change the ~ContextVK() to properly synchronize with the worker thread and destroy the CommandPoolVK