windows rls stderr: thread 'main' has overflowed its stack

[alexheretic]

Initially reported rust-lang/atom-ide-rust#75. Soon after starting rls reports thread 'main' has overflowed its stack on stderr. This seems to be the cause of rls not working for this project.

Steps to reproduce

• Install windows
• git clone https://github.com/dannyfritz/learn-glium
• run rustup run nightly rls --cli

This produces

Initializing (look for `progress[done:true]` message)...
> 1: InitializeResult {
    capabilities: ServerCapabilities {
        text_document_sync: Some(
            Kind(
                Incremental
            )
        ),
        hover_provider: Some(
            true
        ),
        completion_provider: Some(
            CompletionOptions {
                resolve_provider: Some(
                    true
                ),
                trigger_characters: Some(
                    [
                        ".",
                        ":"
                    ]
                )
            }
        ),
        signature_help_provider: None,
        definition_provider: Some(
            true
        ),
        references_provider: Some(
            true
        ),
        document_highlight_provider: Some(
            true
        ),
        document_symbol_provider: Some(
            true
        ),
        workspace_symbol_provider: Some(
            true
        ),
        code_action_provider: Some(
            true
        ),
        code_lens_provider: None,
        document_formatting_provider: Some(
            true
        ),
        document_range_formatting_provider: Some(
            false
        ),
        document_on_type_formatting_provider: None,
        rename_provider: Some(
            true
        ),
        execute_command_provider: Some(
            ExecuteCommandOptions {
                commands: [
                    "rls.applySuggestion",
                    "rls.deglobImports"
                ]
            }
        )
    }
}
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_1","title":"Building"}}
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_1","message":"glium","title":"Building"}}

thread 'main' has overflowed its stack

[nrc]

Do you have a stack trace? I'm aware of Racer causing this problem sometimes, I've not seen it happen due to the compiler or RLS. Could test by disabling Racer completion and seeing if it reproduces.

[dannyfritz]

Can you provide me more information about disabling racer and retrying it? The output you see above is all I've seen too when running rustup run nightly rls --cli.

No stack trace from what I can tell. I do have RUST_BACKTRACE=1.

With stable I don't get an error and it works.

[nrc]

Can you provide me more information about disabling racer and retrying it?

In your user settings, set rust.racer_completion to false.

[dannyfritz]

Adding "rust.racer_completion": false to my VSCode config doesn't fix it when set to the nightly toolchain. So far only changing the toolchain to stable fixes it.

[alexheretic]

Since this is/was reproduced by rustup run nightly rls --cli on startup I don't beleive the client sends any requests so racer shouldn't be involved. No backtrace is available for the reported error.

Running the steps on the latest nighty produces a new error thread '<unnamed>' panicked at 'Could not convert URI to path: ()', libcore\result.rs:945:5

It still cargo +nightly checks fine.

$ rustup run nightly rls --cli
Initializing (look for `progress[done:true]` message)...
> 1: InitializeResult {
    capabilities: ServerCapabilities {
        text_document_sync: Some(
            Kind(
                Incremental
            )
        ),
        hover_provider: Some(
            true
        ),
        completion_provider: Some(
            CompletionOptions {
                resolve_provider: Some(
                    true
                ),
                trigger_characters: Some(
                    [
                        ".",
                        ":"
                    ]
                )
            }
        ),
        signature_help_provider: None,
        definition_provider: Some(
            true
        ),
        references_provider: Some(
            true
        ),
        document_highlight_provider: Some(
            true
        ),
        document_symbol_provider: Some(
            true
        ),
        workspace_symbol_provider: Some(
            true
        ),
        code_action_provider: Some(
            true
        ),
        code_lens_provider: None,
        document_formatting_provider: Some(
            true
        ),
        document_range_formatting_provider: Some(
            false
        ),
        document_on_type_formatting_provider: None,
        rename_provider: Some(
            true
        ),
        execute_command_provider: Some(
            ExecuteCommandOptions {
                commands: [
                    "rls.applySuggestion",
                    "rls.deglobImports"
                ]
            }
        )
    }
}
thread '<unnamed>' panicked at 'Could not convert URI to path: ()', libcore\result.rs:945:5
stack backtrace:
   0: <std::collections::hash::map::DefaultHasher as core::fmt::Debug>::fmt
   1: core::str::<impl str>::encode_utf16
   2: std::panicking::take_hook
   3: std::panicking::take_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: _rust_maybe_catch_panic
  15: <unknown>
  16: std::process::id
  17: std::sys::windows::thread::Thread::new
  18: BaseThreadInitThunk
  19: RtlUserThreadStart

[eddyb]

Having the exact same issue with a glium dependency. Is there any way to blacklist it?

[nrc]

Using RLS on the command line with today's nightly Rust and RLS master I get a bunch of compile errors, but no panic and no stack overflow.

[nrc]

In VSCode I'm also not seeing a panic or stack overflow but I am seeing the errors in logs, but no report to the user.

[nrc]

Whoops, missed that this was Windows only, that would explain why I'm not seeing it.

[dannyfritz]

I'm getting the same error with nightly-x86_64-pc-windows-msvc - rustc 1.28.0-nightly (cb20f68d0 2018-05-21)

[nrc]

If someone who can reproduce on Windows could run a debug build of the RLS and get a backtrace, that would be really useful

[dannyfritz]

I cloned this repo and compiled rls. How do I use it with a path or attach it to cargo?

C:\Users\danny\Dev\rls (master)
λ cargo +nightly run -- --help
    Finished dev [unoptimized + debuginfo] target(s) in 0.43s
     Running `target\debug\rls.exe --help`

    --version or -V to print the version and commit info
    --help or -h for this message
    --cli starts the RLS in command line mode
    No input starts the RLS as a language server


C:\Users\danny\Dev\rls (master)
λ cargo +nightly run -- -V
    Finished dev [unoptimized + debuginfo] target(s) in 0.43s
     Running `target\debug\rls.exe -V`
rls-preview 0.128.0-nightly (cf3961d 2018-05-23)

C:\Users\danny\Dev\rls (master)
λ