Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
twrecked opened this issue Nov 29, 2024 · 3 comments
Open

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

twrecked opened this issue Nov 29, 2024 · 3 comments
Labels
bug Something isn't working Look into 👀

Comments

@twrecked
Copy link

(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.

@artempyanykh
Copy link
Owner

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

@artempyanykh artempyanykh added bug Something isn't working Look into 👀 labels Dec 4, 2024
@w31mann
Copy link

w31mann commented Dec 8, 2024

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.

artempyanykh added a commit that referenced this issue Dec 14, 2024
…ders request

Sometimes, LSP clients can send bogus folders (CWD, or homedir) as part
of added folders in didChangeWorkspaceFolders. Whenever this happens
marksman treats the root as the real root of the project folders and
recursively scans/indexes mardown documents underneath.This is
problematic when such root is a homedir because it makes marksman scan
too much and potentially fail.

Fixes #377
Potentially, addresses #373 too
artempyanykh added a commit that referenced this issue Dec 14, 2024
…ders request

Sometimes, LSP clients can send bogus folders (CWD, or homedir) as part
of added folders in didChangeWorkspaceFolders. Whenever this happens
marksman treats the root as the real root of the project folders and
recursively scans/indexes mardown documents underneath.This is
problematic when such root is a homedir because it makes marksman scan
too much and potentially fail.

Fixes #377
Potentially, addresses #373 too

stack-info: PR: #380, branch: artempyanykh/stack/17
@artempyanykh
Copy link
Owner

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

artempyanykh added a commit that referenced this issue Dec 14, 2024
…ders request

Sometimes, LSP clients can send bogus folders (CWD, or homedir) as part
of added folders in didChangeWorkspaceFolders. Whenever this happens
marksman treats the root as the real root of the project folders and
recursively scans/indexes mardown documents underneath.This is
problematic when such root is a homedir because it makes marksman scan
too much and potentially fail.

Fixes #377
Potentially, addresses #373 too

stack-info: PR: #380, branch: artempyanykh/stack/17
artempyanykh added a commit that referenced this issue Dec 14, 2024
…ders request

Sometimes, LSP clients can send bogus folders (CWD, or homedir) as part
of added folders in didChangeWorkspaceFolders. Whenever this happens
marksman treats the root as the real root of the project folders and
recursively scans/indexes mardown documents underneath.This is
problematic when such root is a homedir because it makes marksman scan
too much and potentially fail.

Fixes #377
Potentially, addresses #373 too

stack-info: PR: #380, branch: artempyanykh/stack/17
artempyanykh added a commit that referenced this issue Dec 14, 2024
…ders request (#380)

Sometimes, LSP clients can send bogus folders (CWD, or homedir) as part
of added folders in didChangeWorkspaceFolders. Whenever this happens
marksman treats the root as the real root of the project folders and
recursively scans/indexes mardown documents underneath.This is
problematic when such root is a homedir because it makes marksman scan
too much and potentially fail.

Fixes #377
Potentially, addresses #373 too
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Look into 👀
Projects
None yet
Development

No branches or pull requests

3 participants