TexLab consumes all the memory

[jakubkaczor]

As in the title, TexLab consumes all the memory. The steps to reproduce are the following.

1. In the home directory, edit a new or existing file. In this step, mostly default configuration of NeoVim's nvim-lspconfig automatically runs TexLab and attaches.

nvim test.tex

2. Switch the focus to the other window (in the window manager, not the editor).

Then the memory usage of TexLab increases rapidly. Additionaly, when in the same home directory I create a new subdirectory, “cd” into it and then open the file, the same happens, but the increase in memory usage is much slower. That is

cd ~
mkdir test
cd test
nvim test.tex

I proceeded with git bisection between v5.2.0 (bad) and v4.3.2 (good), and according to this, and if I did everything correctly, f0d3996 is the first bad commit.

I couldn't see anything in NeoVim's LspLog, but I didn't increase its verbosity level.

[jakubkaczor]

Also, I would like to note, that even on v4.3.2 I notice a big bump in the memory consumption after switching the window focus, to around 3.75 GiB, but it stops there.

[pfoerster]

@jakubkaczor It looks like texlab is loading/parsing way too many files while trying to figure out the dependency tree. Can you create a texlab log file using texlab -vvvv --log-file=/tmp/texlab.log? The server logs files loaded from the disk.

[jakubkaczor]

@pfoerster, sure. Here is the output.

[pfoerster]

@jakubkaczor Sorry the long wait. The log file looks very odd. First of all, it looks like texlab does not report loading any additional documents from the disk. Additionally, it appears like it has loaded the distro twice. Maybe this could be the reason and texlabs keeps loading the distro.

I couldn't see anything in NeoVim's LspLog, but I didn't increase its verbosity level.

Can you try increasing the verbosity level and see if Neovim reports something?

[jakubkaczor]

@jakubkaczor Sorry the long wait. The log file looks very odd. First of all, it looks like texlab does not report loading any additional documents from the disk. Additionally, it appears like it has loaded the distro twice. Maybe this could be the reason and texlabs keeps loading the distro.

One thing I thought may be obvious, but it wasn't: do you expect me to send the log generated with the latest release, latest main, or the commit I firstly experienced the issue with? I assumed the latter and now, when I compile it, I can see a warning that may be related.

warning: unused variable: `document`
   --> src/server.rs:361:13
    |
361 |         let document = workspace.open(
    |             ^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_document`
    |
    = note: `#[warn(unused_variables)]` on by default

Can you try increasing the verbosity level and see if Neovim reports something?

In Neovim configuration I set the running command as

cmd = {"texlab", "-vvvv", "--log-file=/tmp/texlab.log"}

As the file is written, I assume the change was effective, and the verbosity level is as desired. I additionally set NeoVim's LSP log level to trace (the most verbose), and now in :LspLog I mentioned, there is more information. I can see multiple entries with directories outside /home/jakub/test, which is the current working directory I open the test file from. These are siblings of test directory or their descendants. I don't want to expose the directory structure of my home directory, therefore I replaced these with sequences of question marks. Here is the file.
vim-lsp.log

[pfoerster]

@jakubkaczor Thank you for providing the log file.

These are siblings of test directory or their descendants.

It looks like texlab is trying to load your entire home directory into memory. As of texlab 5.4.0, there is a new workspace command which could be helpful here. Can you inspect the dependency graph using texlab.showDependencyGraph, please?

Sorry to ask about your directory structure, but

• Is there a file which the top of the directory tree which includes many files? Then, the server loads the transitive closure.
• Also, is your directory structure very flat so that you have a lot of TeX files in one directory? texlab would load all files in the directory currently.

One thing I thought may be obvious, but it wasn't: do you expect me to send the log generated with the latest release, latest main, or the commit I firstly experienced the issue with?

I think it is more helpful to look at the latest release instead of f0d3996. The server has changed a lot internally in the mean time.

[gi1242]

Hi There,

I'm having the same problem. (I don't know if I can trace it to switching windows.) But when I start off texlab's memory footprint is negligible. After about 20 mins of editing it's climbed to 1.5GB of my system memory.

After a long editing session yesterday I noticed texlab was up to 4GB+ of memory usage.

I'd be happy to give you more info (e.g. output of texlab.showDependencyGraph), except I couldn't figure out how to run it under neovim. (I'm using Arch linux and Neovim in case it makes any difference.)

Any suggestions?

GI

[gi1242]

I just checked that I still have this issue with 5.4.0.

As a temporary work-around, I got my editor to restart texlab periodically. If anyone else uses neovim, and has this issue, then you can use the following in your LSP config file:

local on_attach = function( client, bufnr )
    -- vim.keymap.set(...) and other LSP settings

    -- Kill in texlab periodically to avoid memory leak bug
    if client.name == 'texlab' then
        vim.defer_fn( function ()
            if vim.api.nvim_get_current_buf() == bufnr then
              vim.cmd('LspRestart')
            else
              client.stop()
              print( 'Stopped TexLab' )
            end
          end, 10*60*1000 )
    end
end

and pass it to the setup function in your LSP config.

[pfoerster]

I'd be happy to give you more info (e.g. output of texlab.showDependencyGraph), except I couldn't figure out how to run it under neovim. (I'm using Arch linux and Neovim in case it makes any difference.)

Unfortunately, I am not that familiar with Neovim but you need a way to bind the workspace/executeCommand request to a Neovim command. Maybe, you can take a look at nvim-lspconfig and see how the forward search request is implemented:

https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/texlab.lua

@gi1242 Can you tell me more about the editing session? Does the RAM usage also increase if you are only editing the same files over and over or are you switching between different files/projects?

[gi1242]

@gi1242 Can you tell me more about the editing session? Does the RAM usage also increase if you are only editing the same files over and over or are you switching between different files/projects?

I'm editing the same file only (not switching files, or projects). The issue always happens on my system. Periodically killing texlab (like I did above) makes it somewhat usable (sometimes I also have to quit the editor and restart). But at least now my system isn't freezing due to lack of memory :).

I will try and figure out how to run workspace/executeCommand and send you output.

[gi1242]

OK, I may have something useful: I ran texlab in a limited memory environment. On Linux I do this by

systemd-run -q --user --scope -p MemoryLimit=500M texlab

Now I go about editing as usual (same file, same setup). I notice that texlab doesn't get killed. (If it uses more than 500M memory, it will automatically get killed.)

My guess is that texlab was aggressively caching something (or there was some garbage collection issue), and it felt comfortable taking up my 8GB RAM + 16 GB swap. (When texlab reached 4GB my system was constantly swapping and really slow.)

I'll post back in a few days if I can confirm it's stable.

[pfoerster]

My guess is that texlab was aggressively caching something

Yeah, I think the syntax trees built from the related files are an issue here. Currently, texlab keeps the parse trees of "hidden" but needed documents in memory even though they are not being edited. In this case, it makes more sense to index the file first and then discard the parse tree. I am currently working on a solution.

[jakubkaczor]

@jakubkaczor Thank you for providing the log file.

These are siblings of test directory or their descendants.

It looks like texlab is trying to load your entire home directory into memory. As of texlab 5.4.0, there is a new workspace command which could be helpful here. Can you inspect the dependency graph using texlab.showDependencyGraph, please?

Sorry to ask about your directory structure, but

* Is there a file which the top of the directory tree which includes many files? Then, the server loads the transitive closure.

* Also, is your directory structure very flat so that you have a lot of TeX files in one directory? `texlab` would load all files in the directory currently.

One thing I thought may be obvious, but it wasn't: do you expect me to send the log generated with the latest release, latest main, or the commit I firstly experienced the issue with?

I think it is more helpful to look at the latest release instead of f0d3996. The server has changed a lot internally in the mean time.

I'm sorry I won't be able to dig into it deeper this week. In NeoVim configuration file for the server we have a function determining the root directory. When one of the conditions in the body is satisfied, that is, I have .latexmkrc or .git directory in the directory where the file I am editing is in, then everything works as expected. But when I want to edit a single LaTeX file, it appears texlab walks the directory structure until it reaches what it wants. But I would expect it not to do it at all (single_file_support).

[gi1242]

I am currently working on a solution.

Thank you so much. If it helps: the file I've been noticing issues with is about 200kb (3500 lines). The associated .bib file has about 10,000 entries.

I was working on smaller files on systems with more memory before and never had any issues. Probably because texlab wasn't using enough memory to make my system swap...

[pfoerster]

Can you try out #875, please? It should help when switching between different, unrelated projects.

[gi1242]

OK, I tried it. I was having the trouble even without switching files before; so I tried it on the same file. The memory growth is more managable, but still present. Now when I'm not doing anything, the memory doesn't grow. The more I type the more the memory grows. If I ask it to complete refs and citations from a large file I can quickly get the memory usage up to some 1.5GB.

I'll use it (without a memory quota) for the next week or so and report back.

[clason]

I've been investigating a bit myself on macOS and I cannot quite reproduce this memory growth (with a modest ~450 page project) -- asking for references or citation completion adds a few megabytes of memory, at most, and just typing doesn't change much; the memory usage remains at 100-200MB. The biggest jump comes from citations, so this:

The associated .bib file has about 10,000 entries.

is almost certainly the culprit. Is this a local bib file, or something in your global personal texmf tree? (I discourage people from using "global bibliographies" as these tend to create more problems than add convenience. Also, bibexport or biber --tool are your friends.)

In any case, citation handling looks to be the place to look at for possible optimizations.

[gi1242]

OK, I've been using it for a bit now and the behavior seems consistent: After a long editing session the memory usage climbs to a little less than 1GB. It doesn't seem to increase beyond that (unllike before where it would grow without bound, even when I wasn't using vim).

Memory only grows when I type.

So it's manageable... but probably not ideal. (It's the single highest memory user on my system now; more than firefox, which has some 20 tabs open)

If you think the bib file is the culprit, I'm attaching it. (I know you don't like global bib's, but using this (and bibtool to merge other bibliographies) makes my life a lot simpler...)

If you can reproduce the memory growth, then we have confirmation.

refs.bib.gz

[charleschetty]

Same issue In ArchLinux and neovim

I've been investigating a bit myself on macOS and I cannot quite reproduce this memory growth

Is it possible that the problem is related to the operation system? Just a guess

[DimitrisZav]

If it helps I have same issue on ArchLinux (EndeavourOS) using doom emacs. Texlab can reach 8GB on large documents or when writing for about 4hours.

[pfoerster]

I have found the cause of the memory leak and created a PR (#877) which fixes the issue (quite large diff but most of the changes result from crate splitting). Can you try it out, please?

The memory usage should be stable now. Previously, it was possible to keep increasing the memory usage by repeatedly sending textDocument/didChange notifications to the server.

[pfoerster]

@clason

In any case, citation handling looks to be the place to look at for possible optimizations.

Yeah, there are still some optimizations to be made here. As these large bibliography files rarely change, we can precompute most of the data required to provide completion.

Discarding the parse tree and relying on the index instead would also help here.

[gi1242]

I checked. Memory footprint doesn't grow like it used to. (I'll keep using it this week).

However, now the old bug about pre-compiled headers in issue #845 seems to have resurfaced. Did that patch get affected (or did I mess up).

[pfoerster]

@gi1242

However, now the old bug about pre-compiled headers in issue #845 seems to have resurfaced. Did that patch get affected (or did I mess up).

Thanks for catching this one! This should be fixed now.

[gi1242]

Yes #845 is fixed now. If I see uncontrolled growth in memory, I'll let you know. As of now (even with my large bib files) the memory footprint of texlab is negligible.

Thanks a lot for the quick fix.

[pfoerster]

Closing this issue for now. Please let me know, if you still encounter a problem.