Leaks memory

[epakarin]

Every time you run baleia.once to colorize a buffer, some new memory is reserved that is never freed. If your nvim process stays alive for a very long time, this will eventually consume all the memory in your system and trigger swapping.

I suspect the culprit is dynamically created syntax highlighting groups that are never cleaned up, but I didn't investigate that deeply.

[m00qek]

Hey there, thanks for opening this issue. Are you opening, colorizing and then closing multiple buffers? I checked the code and it is possible to explicitly clear all highlights when a buffer is closed, although I expected those were already being killed when the buffer closes.

[epakarin]

Just one buffer, and it stays open -- I just load new content or replace the buffer contents, then recolor it with baleia.once (although it shouldn't matter if the autocmd is used instead). I think doing this repeatedly over a long lifespan leaves a bunch of syntax highlighting groups in memory.

[m00qek]

I put some thought on this: baleia creates highlight groups and never delete them, but those are created for specific styles and are re-utilized. I think, if any, what might be pilling up are marks(highlight application to a specific (line,column) coordinate. Do you think you could create a script that would allow me to reproduce this issue?

[quolpr]

I am developing https://github.com/quolpr/quicktest.nvim , and found same issue to. And on big loads a lot of memory are leaking. Not sure what is the reason, maybe extmark could be 🤔

The output with 9k lines takes 4gb ram mem and doesn't clean

[quolpr]

@m00qek btw, not related but could you remove print here, it spams messages log 🙂 https://github.com/m00qek/baleia.nvim/blob/4d3b27dbec65a44ceecd9306f605a980bcf4e9b1/lua/baleia/locations/ansi_codes.lua#L32

[m00qek]

Hey, thanks for reaching out. Does it accumulate that much of memory after multiple evals or on a single one?

[quolpr]

@m00qek it looks like mem consumptions is growing line n^k, where k = number of runs. Not sure why, but first run will eat like 1gb, next run 2gb, the next 4gb etc....

[quolpr]

@m00qek after some more closed debug I found the reason why so much mem was eating - it's because vim undo history. I was calling set buf lines a lot, and all this sets were stored in undo history of buffer! I fixed it with:

vim.api.nvim_buf_set_option(buf, "undolevels", -1)

[m00qek]

oh, that makes so much sense. I'll patch it up this weekend: avoid storing changes in history, clean up empty marks, etc. Thank you so much!

[m00qek]

were you calling the dev API or using the user commands to "rewrite the buffer with colors"?

[quolpr]

@m00qek I am using dev API, and actually found another issue. baleia sometime causes nvim crash. It happens on very rapid changes, when I am calling set buff a lot.

Here is the issue https://github.com/quolpr/quicktest.nvim/issues/11

Here how I use it: https://github.com/quolpr/quicktest.nvim/blob/main/lua/quicktest/module.lua#L78

[m00qek]

Do you have any logs to share?

[quolpr]

@m00qek actually can't reproduce crashes anymore, but other users report that crash happen occasionally when using baleia(no crashes without it). Nvim just exit with code 139 without any crash reports