fix: resolve multiple memory leaks causing unbounded RAM growth ( Now passing: && Fixed failing tests for windows )

[sebishogun]

Bus subscriptions in share, plugin, format, and bootstrap were never unsubscribed. Compaction marked tool outputs as cleared but never actually freed the data. FileTime state had no dispose callback.

This patch stores and calls unsubscribe handles, actually clears tool output during compaction, and adds missing dispose callbacks.

Fixes #13230 #9743 #5363 #9151 #9385 #6213 #3530

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found several related PRs that address similar memory leak issues:

Potentially Related PRs:

1. PR fix: resolve memory leaks and zombie processes from missing cleanup handlers #13186 - "fix: resolve memory leaks and zombie processes from missing cleanup handlers"

   • Similar focus on cleanup handlers and preventing memory leaks
   • Related to the same underlying issue of unmanaged resources

2. PR fix(memory): Fix timeout, interval, and subscription cleanup #9148 - "fix(memory): Fix timeout, interval, and subscription cleanup"

   • Addresses subscription cleanup, which is directly mentioned in the current PR

3. PR fix(core): add dispose functions to prevent subscription memory leaks #7914 - "fix(core): add dispose functions to prevent subscription memory leaks"

   • Directly related to adding dispose callbacks for subscriptions

4. PR fix(core): add dispose functions to prevent subscription memory leaks #7032 - "fix(core): add dispose functions to prevent subscription memory leaks"

   • Another dispose function fix for subscription memory leaks

5. PR fix: clear tool output and attachments when pruning to prevent memory leak #7049 - "clear tool output and attachments when pruning to prevent memory leak"

   • Addresses the tool output clearing mentioned in the current PR description

Recommendation: PR #13186 appears to be the most recent and potentially related fix. Consider reviewing it to ensure no overlap with the current PR's changes.

[sebishogun]

It's complementary to #13186, both can be merged; I am solving strictly some bugs I noticed and got affected by and found open issues for; I think this is the most complete out of all the ones that copilot mentions that this is duplicating; all of the others are for single issues; This is really a big problem, I am on a framework desktop and I get opencode oom killed after 2-3 hours; I have 128 gb ram this is not okay

[ks-nothize]

Good work bro. I did something similar using opencode to fix it's own memory leak. As this multiple memory leak problem is affecting the use of it so much and there are many similar unresolved memory leak issues out there. I feel hopeless to wait for the official release thus built my own fixed version using opencode itself......

And the result works well. Now I run using opencode-fixed anywhere and finally no more memory leak (yet).

For your reference too: https://github.com/ks-nothize/opencode/tree/fix/memory-leaks .

[ks-nothize]

Oh, I just run opencode and it auto updated to 1.2.1, which is a very new release, and the memory leak problem seems to be improved much when testing on my home machine!

Will have to try next week at office to see!

[sebishogun]

indeed seemed to have improved but most of these changes I made here seem to have been left out so I still think this is necessary

[sebishogun]

Added another fix for a bug I found in one of my sessions : JDTLS creates a temp directory in /tmp via fs.mkdtemp() for its -data flag, but it's never cleaned up on shutdown. On systems where /tmp is tmpfs-backed (like Arch), these orphaned directories persist in RAM. I have a Framework laptop desktop session balloon to 65 GB of RAM usage over multiple restarts because old jdtls data directories kept accumulating. This adds an optional cleanup callback to LSPServer.Handle that removes the temp directory when the LSP client shuts down, right after killing the process.

[PixelMelt]

lgtm ive crashed like 5 times because of this

[sebishogun]

any hope for this to get merged?

god knows, been updating this for 2 weeks now, might be the case that in the end they fix all the issues by themselves

[sebishogun]

@adamdotdevin @Hona All issues regarding memory leaks have been addressed so far, so this pr is almost irrelevant now, just 2 more things remain in the diff to dev:

1. Memory leak — cleanup callback for FileTime.state (clears read map + locks on disposal)
2. Windows mtime — uses filesystem mtime instead of new Date() to avoid NTFS clock divergence ;

Let me know if this is relevant or I should close it. (thanks for fixing all those memory leaks :D )