Memory Leak in `GarbageCollector` due to uncleared `to_remove` map

[themiguelamador]

Bug Description

A memory leak has been identified in the live_debugger library, specifically in the GarbageCollector GenServer. The leak is caused by the to_remove map in the GarbageCollector's state, which grows indefinitely without being cleaned up.

The GarbageCollector is responsible for periodically cleaning up ETS tables and other resources used by the debugger. It uses a to_remove map to keep track of the processes that are marked for deletion. When a process is garbage collected, its pid is supposed to be removed from the to_remove map. However, this is not happening.

The bug is located in the handle_info(:garbage_collect, ...) function in lib/live_debugger/services/garbage_collector/gen_servers/garbage_collector.ex. This function recalculates the to_remove map in each cycle, but it never cleans up the old entries.

As a result, the to_remove map grows indefinitely, causing a memory leak. This is especially noticeable in development environments where the live_debugger is active and many LiveViews are being created and destroyed.

Actual Behavior

When the live_debugger is enabled in a Phoenix LiveView application, the memory usage of the BEAM process grows over time and never decreases, even with low activity. This eventually leads to the application crashing due to an out-of-memory error.

Expected Behavior

The memory usage of the BEAM process should remain stable over time, and it should not grow indefinitely when the live_debugger is enabled.

Steps to Reproduce

1. Enable the live_debugger in a Phoenix LiveView application.
2. Navigate through the application, creating and destroying LiveViews.
3. Monitor the memory usage of the BEAM process.
4. Observe that the memory usage grows over time and never decreases.

Elixir version with Erlang/OTP

Erlang/OTP 28 [erts-16.1.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit] [dtrace] Elixir 1.19.3 (compiled with Erlang/OTP 28)

LiveDebugger version

0.4.3

Phoenix version

1.8.1

Phoenix LiveView version

1.1.17

Operating system

darwin

Browser(s)

Brave

[themiguelamador]

Proposed Solution:

The bug can be fixed by modifying the handle_info(:garbage_collect, ...) function in lib/live_debugger/services/garbage_collector/gen_servers/garbage_collector.ex to remove the garbage-collected pids from the to_remove map.

Here's a patch that may fix the bug:

--- a/lib/live_debugger/services/garbage_collector/gen_servers/garbage_collector.ex
+++ b/lib/live_debugger/services/garbage_collector/gen_servers/garbage_collector.ex
@@ -37,11 +37,21 @@
     to_remove1 = GarbageCollectingActions.garbage_collect_traces!(state, watched_pids, alive_pids)
     to_remove2 = GarbageCollectingActions.garbage_collect_states!(state, watched_pids, alive_pids)
 
-    loop_garbage_collection()
+    loop_garbage_collection() 
 
-    to_remove = Map.intersect(to_remove1, to_remove2, fn _, cnt1, cnt2 -> min(cnt1, cnt2) end)
+    to_remove =
+      Map.merge(to_remove1, to_remove2, fn _, cnt1, cnt2 ->
+        min(cnt1, cnt2)
+      end)
+      |> Map.merge(state.to_remove, fn _, cnt1, cnt2 ->
+        min(cnt1, cnt2)
+      end)
+
+    pids_to_keep = Map.keys(to_remove1) ++ Map.keys(to_remove2) |> MapSet.new()
+
+    to_remove =
+      to_remove
+      |> Map.take(MapSet.to_list(pids_to_keep))
 
     {:noreply, %{state | to_remove: to_remove}}
   end

This patch modifies the handle_info(:garbage_collect, ...) function to correctly merge the to_remove maps and then remove the pids that are no longer being tracked. This will prevent the to_remove map from growing indefinitely and may fix the memory leak.

[kraleppa]

Hey, @themiguelamador thanks for reporting 😄 The code you described and to_remove function is not present at v0.4.3 version - it's on the main branch, but it has not been released yet (it'll be released in LiveDebugger v0.5.0).

Can you confirm what version of LiveDebugger you're using? Is it LiveDebugger fetched directly from main or v0.4.3

[themiguelamador]

v0.4.3, so should be fixed with the new release then.

…

On Mon, Nov 24, 2025 at 2:56 PM Krzysztof Nalepa ***@***.***> wrote: *kraleppa* left a comment (software-mansion/live-debugger#855) <#855 (comment)> Hey, @themiguelamador <https://github.com/themiguelamador> thanks for reporting 😄 The code you described and to_remove function is not present at v0.4.3 version - it's on the main branch, but it has not been released yet (it'll be released in LiveDebugger v0.5.0). Can you confirm what version of LiveDebugger you're using? Is it LiveDebugger directly from main branch, or v0.4.3 — Reply to this email directly, view it on GitHub <#855 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWO57G66UOIK3KZ7WWIFYD36MMCNAVCNFSM6AAAAACM5KFC5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZRGIYDCNRTGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kraleppa]

@themiguelamador I can’t reproduce this on my side - is there a chance you could share more detailed reproduction steps? It would help to know what these LiveViews are doing, how frequently they update, how frequently you switch those LiveViews and whether the leak correlates with rapid state changes or specific interactions.

Did this memory leak occur only once, or is it something that happens consistently over time? If possible, any info about the debugger session length, or the number of active LiveViews at the moment of the leak would also be super useful.

Thanks in advance - happy to dig deeper once we have more context.

FYI
If you're curious how I tried to reproduce it, here's a description:
I created a mock LiveView that sends to itself large messages every 100ms. When LiveView mounts, it chooses randomly how many messages it should send from such list [10, 100, 1000]. When message is received it is added to assigns and displayed. When LiveView sends declared number of messages it redirects to itself. It should simulate a case when massive LiveViews are destroyed and created fast.

When I started the experiment, VM memory was rising and falling down

Also, when I spammed the refresh button really fast the size of grew, but went down after couple of seconds