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

[alexheretic]

Initially reported https://github.com/mehcode/atom-ide-rust/issues/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)
λ

[dannyfritz]

Ran it in --cli mode and got the error:

C:\Users\danny\Dev\rls (master)
λ cargo +nightly run -- --cli
    Finished dev [unoptimized + debuginfo] target(s) in 0.43s
     Running `target\debug\rls.exe --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:     0x7ff9e0d44cd5 - <std::collections::hash::map::DefaultHasher as core::fmt::Debug>::fmt::h0923ab9a0420c3d3
   1:     0x7ff9e0d4781f - std::net::tcp::TcpStream::set_nonblocking::hff7bb610ab37a708
   2:     0x7ff9e0d4e7b5 - std::panicking::take_hook::hb535c1add77d7294
   3:     0x7ff9e0d4e456 - std::panicking::take_hook::hb535c1add77d7294
   4:     0x7ff9e0d4eede - std::panicking::rust_panic_with_hook::h250cb9c9d6e43737
   5:     0x7ff9e0d4ea76 - std::panicking::begin_panic_fmt::h7c0d28d60050632c
   6:     0x7ff9e0d4ea2f - rust_begin_unwind
   7:     0x7ff9e0d84e2c - core::panicking::panic_fmt::hf111b6e18c32893e
   8:     0x7ff7f8481435 - core::result::unwrap_failed<()>
                               at C:\projects\rust\src\libcore\macros.rs:26
   9:     0x7ff7f70f822f - core::result::Result<std::path::PathBuf, ()>::expect<std::path::PathBuf,()>
                               at C:\projects\rust\src\libcore\result.rs:809
  10:     0x7ff7f71370dc - rls::server::get_root_path::{{closure}}
                               at C:\Users\danny\Dev\rls\src\server\mod.rs:391
  11:     0x7ff7f741ce54 - core::option::Option<url::Url*>::map<url::Url*,std::path::PathBuf,closure>
                               at C:\projects\rust\src\libcore\option.rs:404
  12:     0x7ff7f737217a - rls::server::get_root_path
                               at C:\Users\danny\Dev\rls\src\server\mod.rs:386
  13:     0x7ff7f729a1be - rls::server::{{impl}}::handle<rls::cmd::PrintlnOutput>
                               at C:\Users\danny\Dev\rls\src\server\mod.rs:129
  14:     0x7ff7f72f8571 - rls::server::message::Request<languageserver_types::request::Initialize>::blocking_dispatch<languageserver_types::request::Initialize,rls::cmd::PrintlnOutput>
                               at C:\Users\danny\Dev\rls\src\server\message.rs:185
  15:     0x7ff7f71295a5 - rls::server::LsService<rls::cmd::PrintlnOutput>::dispatch_message<rls::cmd::PrintlnOutput>
                               at C:\Users\danny\Dev\rls\src\server\mod.rs:255
  16:     0x7ff7f7134967 - rls::server::LsService<rls::cmd::PrintlnOutput>::handle_message<rls::cmd::PrintlnOutput>
                               at C:\Users\danny\Dev\rls\src\server\mod.rs:330
  17:     0x7ff7f711394e - rls::server::LsService<rls::cmd::PrintlnOutput>::run<rls::cmd::PrintlnOutput>
                               at C:\Users\danny\Dev\rls\src\server\mod.rs:164
  18:     0x7ff7f747174c - rls::cmd::init::{{closure}}
                               at C:\Users\danny\Dev\rls\src\cmd.rs:467
  19:     0x7ff7f746ebf7 - std::sys_common::backtrace::__rust_begin_short_backtrace<closure,()>
                               at C:\projects\rust\src\libstd\sys_common\backtrace.rs:136
  20:     0x7ff7f714090c - std::thread::{{impl}}::spawn::{{closure}}::{{closure}}<closure,()>
                               at C:\projects\rust\src\libstd\thread\mod.rs:409
  21:     0x7ff7f73a19d7 - std::panic::{{impl}}::call_once<(),closure>
                               at C:\projects\rust\src\libstd\panic.rs:305
  22:     0x7ff7f7294eea - std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure>,()>
                               at C:\projects\rust\src\libstd\panicking.rs:310
  23:     0x7ff9e0d800a1 - _rust_maybe_catch_panic
  24:     0x7ff7f7291166 - std::panicking::try<(),std::panic::AssertUnwindSafe<closure>>
                               at C:\projects\rust\src\libstd\panicking.rs:289
  25:     0x7ff7f73a3677 - std::panic::catch_unwind<std::panic::AssertUnwindSafe<closure>,()>
                               at C:\projects\rust\src\libstd\panic.rs:374
  26:     0x7ff7f713f954 - std::thread::{{impl}}::spawn::{{closure}}<closure,()>
                               at C:\projects\rust\src\libstd\thread\mod.rs:408
  27:     0x7ff7f7141004 - alloc::boxed::{{impl}}::call_box<(),closure>
                               at C:\projects\rust\src\liballoc\boxed.rs:638
  28:     0x7ff9e0d7f076 - std::sync::mpsc::blocking::WaitToken::wait_max_until::hedd9f43f00393067
  29:     0x7ff9e0d52388 - std::sys::windows::thread::Thread::new::hf3892245166a6cfb
  30:     0x7ffa24c43033 - BaseThreadInitThunk
  31:     0x7ffa24ef1550 - RtlUserThreadStart
?
Unknown action. Type 'help' to see available actions.
> help
RLS command line interface.

Line and column numbers are zero indexed

Supported commands:
    help          display this message
    quit          exit

    def           file_name line_number column_number
                  textDocument/definition
                  used for 'goto def'

    rename        file_name line_number column_number new_name
                  textDocument/rename
                  used for 'rename'

    hover         file_name line_number column_number
                  textDocument/hover
                  used for 'hover'

    symbol        query
                  workspace/symbol

    document      file_name
                  textDocument/documentSymbol

    format        file_name [tab_size [insert_spaces]]
                  textDocument/formatting
                  tab_size defaults to 4 and insert_spaces to 'true'

    range_format  file_name start_line start_col end_line end_col [tab_size [insert_spaces]]
                  textDocument/rangeFormatting
                  tab_size defaults to 4 and insert_spaces to 'true'

    code_action   file_name start_line start_col end_line end_col
                  textDocument/codeAction

    resolve       label detail
                  completionItem/resolve
> quit
thread 'main' panicked at 'Error sending on channel: "SendError(..)"', libcore\result.rs:945:5
stack backtrace:
   0:     0x7ff9e0d44cd5 - <std::collections::hash::map::DefaultHasher as core::fmt::Debug>::fmt::h0923ab9a0420c3d3
   1:     0x7ff9e0d4781f - std::net::tcp::TcpStream::set_nonblocking::hff7bb610ab37a708
   2:     0x7ff9e0d4e7b5 - std::panicking::take_hook::hb535c1add77d7294
   3:     0x7ff9e0d4e456 - std::panicking::take_hook::hb535c1add77d7294
   4:     0x7ff9e0d4eede - std::panicking::rust_panic_with_hook::h250cb9c9d6e43737
   5:     0x7ff9e0d4ea76 - std::panicking::begin_panic_fmt::h7c0d28d60050632c
   6:     0x7ff9e0d4ea2f - rust_begin_unwind
   7:     0x7ff9e0d84e2c - core::panicking::panic_fmt::hf111b6e18c32893e
   8:     0x7ff7f710dca6 - core::result::unwrap_failed<std::sync::mpsc::SendError<alloc::string::String>>
                               at C:\projects\rust\src\libcore\macros.rs:26
   9:     0x7ff7f70f7ad3 - core::result::Result<(), std::sync::mpsc::SendError<alloc::string::String>>::expect<(),std::sync::mpsc::SendError<alloc::string::String>>
                               at C:\projects\rust\src\libcore\result.rs:809
  10:     0x7ff7f745df12 - rls::cmd::run
                               at C:\Users\danny\Dev\rls\src\cmd.rs:175
  11:     0x7ff7f72971c9 - rls::main
                               at C:\Users\danny\Dev\rls\src\main.rs:91
  12:     0x7ff7f730c05f - std::rt::lang_start::{{closure}}<()>
                               at C:\projects\rust\src\libstd\rt.rs:74
  13:     0x7ff9e0d4e976 - std::panicking::update_panic_count::hf9ce2eceb6ff17d2
  14:     0x7ff9e0d800a1 - _rust_maybe_catch_panic
  15:     0x7ff9e0d447d5 - std::rt::lang_start_internal::hb5dae153f6acd70a
  16:     0x7ff7f730c037 - std::rt::lang_start<()>
                               at C:\projects\rust\src\libstd\rt.rs:74
  17:     0x7ff7f7297772 - main
  18:     0x7ff7f9268f0b - invoke_main
                               at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  19:     0x7ff7f9268f0b - __scrt_common_main_seh
                               at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283
  20:     0x7ffa24c43033 - BaseThreadInitThunk
  21:     0x7ffa24ef1550 - RtlUserThreadStart
error: process didn't exit successfully: `target\debug\rls.exe --cli` (exit code: 101)

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

[dannyfritz]

I don't have a C:\projects directory on my computer.

[nrc]

Ran it in --cli mode and got the error

Awesome, thank you!

[nrc]

@dannyfritz could you run again please? But add the following before https://github.com/rust-lang-nursery/rls/blob/master/src/server/mod.rs#L391:

eprintln!("uri: {:?}", uri);

[dannyfritz]

uri: "file:////?\\C:\\Users\\danny\\Dev\\rls"

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

[alexheretic]

The could no convert URI error is another Windows issue unrelated to the stack overflow. Related: https://github.com/rust-lang/rust/issues/42869.

After resolving the UNC path thing _(I'll raise a pr)_ we're back to thread 'main' has overflowed its stack. There is no stack trace. It looks like this occurs while building glium.

Output _(with InitializeResult contents removed)_:

λ cargo +nightly run --manifest-path=C:\Users\alex\project\rls\Cargo.toml -- --cli                                                           
   Compiling rls v0.128.0 (file:///C:/Users/alex/project/rls)                                                                                
    Finished dev [unoptimized + debuginfo] target(s) in 15.75s                                                                               
     Running `C:\Users\alex\project\rls\target\debug\rls.exe --cli`                                                                          
Initializing (look for `progress[done:true]` message)...                                                                                     
> 1: InitializeResult { ... }                                                                                                                                            
{"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                                                                                                       

Sometimes at this point windows will notify me that rls.exe has crashed. Sometimes the output prints a little more, but rls is still kaput.

{"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
{"jsonrpc":"2.0","method":"window/progress","params":{"done":true,"id":"progress_1","title":"Building"}}
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_0","title":"Indexing"}}
{"jsonrpc":"2.0","method":"window/showMessage","params":{"message":"Cargo failed: Error compiling dependent crate","type":1}}
{"jsonrpc":"2.0","method":"window/progress","params":{"done":true,"id":"progress_0","title":"Indexing"}}