artempyanykh/marksman

can't edit files in my home or home/tmp directory

Opened this issue · 3 comments

(This feels related to #370 and #348, apologies for opening a new bug.)

I'm using Ubuntu 24.04.1 but I've also seen the issue on a custom linux distribution as well. I've installed marksman via the astronvim package.

If I run nvim using any of these combinations of commands it will:

cd; nvim new.md
cd ~/tmp; nvim ~/new.md 
cd ~/tmp; nvim new.md
cd ~/etc; nvim ~/new.md
cd ~/etc; nvim ~/tmp/new.md

marksman fails with this error:

Client marksman quit with exit code 1 and signal 0. Check log for errors: /home/steve/.local/state/nvim/lsp.log

But if I run like this, it works:

cd etc; nvim new.md
cd src; nvim new.md

It looks like files in my home and tmp are causing it problems.

LspInfo shows this when it fails:

LSP configs active in this buffer (bufnr: 1) ~
- Language client log: ~/.local/state/nvim/lsp.log
- Detected filetype: `markdown`
- 1 client(s) attached to this buffer
- Client: `null-ls` (id: 1, bufnr: [1])
  root directory:    ~/etc/
  filetypes:         handlebars, typescriptreact, vue, markdown.mdx, yaml, jsonc, typescript, less, html, htmlangular, graphql, css, svelte, javascriptreact, javascript, markdown, json, astro, scss, python, lua, luau
  cmd:               ~/etc/<function>
  version:           ? (cmd is a function)
  executable:        NA
  autostart:         false
- Other clients that match the "markdown" filetype:
- Config: marksman
  filetypes:         markdown, markdown.mdx
  cmd:               ~/.local/share/nvim/mason/bin/marksman server
  version:           `1.0.0-1a62211+1a6221101c37734cc76175deb0fc11a8cad66de6`
  executable:        true
  autostart:         true
  root directory:    Not found.

LspInfo shows this when it works:

LSP configs active in this buffer (bufnr: 1) ~
- Language client log: ~/.local/state/nvim/lsp.log
- Detected filetype: `markdown`
- 2 client(s) attached to this buffer
- Client: `marksman` (id: 1, bufnr: [1])
  root directory:    ~/etc/
  filetypes:         markdown, markdown.mdx
  cmd:               ~/.local/share/nvim/mason/bin/marksman server
  version:           `1.0.0-1a62211+1a6221101c37734cc76175deb0fc11a8cad66de6`
  executable:        true
  autostart:         true
- Client: `null-ls` (id: 2, bufnr: [1])
  root directory:    ~/etc/
  filetypes:         python, json, scss, javascriptreact, javascript, typescript, svelte, jsonc, markdown.mdx, yaml, htmlangular, vue, graphql, markdown, less, astro, typescriptreact, html, handlebars, css, luau, lua
  cmd:               ~/etc/<function>
  version:           ? (cmd is a function)
  executable:        NA
  autostart:         false

The most obvious difference being the root directory entry but I have no idea what that implies.

The log generated is:


[ERROR][2024-11-29 16:45:39] .../vim/lsp/rpc.lua:770	"rpc"	"/home/steve/.local/share/nvim/mason/bin/marksman"	"stderr"	"System.AggregateException: One or more errors occurred. (MailboxProcessor.PostAndAsyncReply timed out.)\n
 ---> System.TimeoutException: MailboxProcessor.PostAndAsyncReply timed out.\n
   at <StartupCode$FSharp-Core>.$Mailbox.PostAndAsyncReply@497-1.Invoke(FSharpOption`1 res) in D:\\a\\_work\\1\\s\\src\\FSharp.Core\\mailbox.fs:line 498\n
   at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvokeNoHijackCheck[a,b](AsyncActivation`1 ctxt, b result1, FSharpFunc`2 userCode) in D:\\a\\_work\\1\\s\\src\\FSharp.Core\\async.fs:line 528\n
   at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction) in D:\\a\\_work\\1\\s\\src\\FSharp.Core\\async.fs:line 112\n
   --- End of inner exception stack trace ---\n
   at Ionide.LanguageServerProtocol.Server.startWithSetup[client](FSharpFunc`2 setupRequestHandlings, Stream input, Stream output, FSharpFunc`2 clientCreator, FSharpFunc`2 customizeRpc) in /home/runner/work/marksman/marksman/LanguageServerProtocol/LanguageServerProtocol.fs:line 205\n
   at Ionide.LanguageServerProtocol.Server.start@309-2.Invoke(FSharpFunc`2 customizeRpc)\n
   at Marksman.Program.startLSP(Int32 verbosity, Boolean waitForDebugger) in /home/runner/work/marksman/marksman/Marksman/Program.fs:line 57\n
   at Marksman.Program.lspCommand@86.Invoke(Tuple`2 tupledArg)\n
   at FSharp.SystemCommandLine.CommandBuilders.SetHandlerInt@207-2.Invoke(InvocationContext ctx)\n
   at System.CommandLine.Invocation.AnonymousCommandHandler.Invoke(InvocationContext)\n
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass17_0.<<UseParseErrorReporting>b__0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass19_0.<<UseTypoCorrections>b__0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__18_0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseDirective>b__0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__5_0>d.MoveNext()\n
--- End of stack trace from previous location ---\n
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass8_0.<<UseExceptionHandler>b__0>d.MoveNext()\n
"

Thanks.

Thanks for reporting @twrecked! Yeah, something's off here. Need a closer look.

Not 100% sure but I guess I'm facing a similar or the same issue.

IMO, the problem is that marksman is indexing all files in the root dir on startup which might takes quiet some time in directories with a lot of files. If there is a request for the language server during that time, marksman will bail out with a stack trace.

File indexing seams to be here, generating loads of log messages like the following.

[ERROR][2024-12-08 13:04:44] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:04:44 VRB] <Folder> Skipping ignored file: {"file": "/home/user/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/trait.impl/core/core_simd/simd/num/int/trait.SimdInt.js"}

Then it gets stuck for a few minutes after logging the following messages, generated here.

[ERROR][2024-12-08 13:04:44] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	"[13:04:44 VRB] <Conn> mk: full rebuild started: {}\n"
[ERROR][2024-12-08 13:04:44] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:04:44 VRB] <Conn> update: started: {"#removed": 0, "#added": 101909}

Finishing off with...

[ERROR][2024-12-08 13:07:14] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:14 VRB] <Conn> Finished updating conn: {"elapsed_ms": 149731, "#touched": 101909}\n'
[ERROR][2024-12-08 13:07:14] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:14 VRB] <StateManager> Updating state: {"nextRev": 1, "curRev": 0}\n'
[ERROR][2024-12-08 13:07:14] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:14 VRB] <StateManager> Processing a hook: {"curRev": 1, "prevRev": "Some(0)", "name": "diag"}\n'
[ERROR][2024-12-08 13:07:14] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:14 VRB] <StateManager> Received a message: {"type": "MutateState"}\n'
[ERROR][2024-12-08 13:07:14] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:14 VRB] <StateManager> Updating state: {"nextRev": 2, "curRev": 1}\n'
[ERROR][2024-12-08 13:07:14] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:14 VRB] <StateManager> Processing a hook: {"curRev": 2, "prevRev": "Some(1)", "name": "diag"}\n[13:07:14 VRB] <StateManager> Received a message: {"type": "ReadState"}\n'
[ERROR][2024-12-08 13:07:15] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:15 VRB] <LSP Server> Updating folder diag: {"num_docs": 7303, "folder": "{ uri = \\"file:///home/user\\"\\n  data = RootPath (AbsPath \\"/home/user\\") }"}\n'
[ERROR][2024-12-08 13:07:15] .../vim/lsp/rpc.lua:770	"rpc"	"/home/user/.local/share/nvim/mason/bin/marksman"	"stderr"	'[13:07:15 VRB] <LSP Server> Diagnostic changed, queueing the update: {"doc": ".cargo/registry/src/index.crates.io-6f17d22bba15001f/addr2line-0.21.0/README.md"}\n'

In this case the whole startup took over 3 minutes. During that time the CPU load is at 100% for a single thread. If you are patient enough to leave it alone, not generating any lsp calls, marksman seams to be ok. If not you will get the stack trace.

I think #380 should address/workaround it. A bit more details in LazyVim/LazyVim#5074