Rls: RLS crashes in VSCode

[rnleach]

It just crashes on any project in Ubuntu 16.04. Chatted about it in #rust-tools with @jonathandturner and it seems it has something to do with latest rustup release.

[jntrnr]

https://github.com/rust-lang/rust/pull/41900 just landed. With luck, this should roll out soon.

[jntrnr]

No luck... still seeing the crash even with the updated nightly

[FaultyRAM]

I'm also getting crashes with VSCode, but on Windows 10 Pro x64 1703.

thread 'main' panicked at 'unknown action', src\tools\rls\src\cmd.rs:78
stack backtrace:
   0:     0x7ff9866f502d - <std::time::SystemTimeError as core::fmt::Display>::fmt::h47b84a1015a24260
   1:     0x7ff986706491 - std::panicking::Location::line::had6a4712d93afde3
   2:     0x7ff986705f00 - std::panicking::Location::line::had6a4712d93afde3
   3:     0x7ff986706b01 - std::panicking::rust_panic_with_hook::hdc062cb76d0a48fb
   4:     0x7ff7956f7cb3 - <unknown>
   5:     0x7ff7957f0617 - <unknown>
   6:     0x7ff986709c41 - _rust_maybe_catch_panic
   7:     0x7ff98670733e - std::rt::lang_start::h19174a93e3fecee2
   8:     0x7ff796011dd8 - git_odb_object_id
   9:     0x7ff9bf5a2773 - BaseThreadInitThunk
thread '<unnamed>' panicked at 'Error reading from channel: RecvError', src\libcore\result.rs:859
[Error - 16:50:00] Connection to server got closed. Server will not be restarted.

[zimond]

My RLS is also crashing, but with a different message: messing field "experimental"

[Doaxan]

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: Message("missing field `experimental`"), line: 0, column: 0 }', /checkout/src/libcore/result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.
[Error - 5:10:26 PM] Connection to server got closed. Server will not be restarted.

With RUST_BACKTRACE=1

DEBUG:rls::server: Language Server Starting up
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: Message("missing field `experimental`"), line: 0, column: 0 }', /checkout/src/libcore/result.rs:859
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:471
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:69
   9: core::result::unwrap_failed
  10: rls::server::parse_message
  11: rls::server::MessageReader::parsed_message
  12: rls::server::LsService::run
  13: rls::main
  14: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  15: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:433
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:56
  16: __libc_start_main
  17: <unknown>

[Enet4]

I'm replicating some information from editor-rs/vscode-rust#229, because I've looked into the matter and it might not be more an issue with the Rust extension than I had initially thought.

The RLS type definition ClientCapabilties was recently changed from a generic JSON value to a JSON object with the fields "workspace", "textDocument" and "experimental", in accordance to the language server protocol. Although we could just make sure that the extension always provides the three fields, the specification on initializing requests explicitly states that "a missing property should be interpreted as an absence of the capability", and not as a problem with the client. Would it be sufficient if we gave these fields default values when deserializing? :)

Edit: There's an issue over at gluon-lang/languageserver-types#14 already.

[Marwes]

0.9.0 (with the required fixed) of languageserver-types is now published

[chengyuhui]

When will the fix be available in rustup?

[Enet4]

Since nightly builds are updated nearly daily (upon new passing changes in the master branch) , it should become available tomorrow. Meanwhile, you can build RLS from source yourself.

[chengyuhui]

It crashes...

[rnleach]

I just ran rustup, my nightly is now at 2017-05-12 and it still crashes.

On Fri, May 12, 2017 at 7:13 PM, Harry Cheng [e-mail]
wrote:

[image: image]
https://cloud.githubusercontent.com/assets/1381736/26021244/6b010854-37bc-11e7-8344-bc93f4f245ce.png
It crashes...

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/rls/issues/312#issuecomment-301216146,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJSF1pyn2eWpJ7oxo7gXX0LhFF-D3uiTks5r5QO8gaJpZM4NXgn3
.

[jntrnr]

@nrc - did you update the submodule in rustc when you closed this? To be on the safe side, reopening this until we can confirm the fix works via rustup, since that's how most people will get it.

[chengyuhui]

@jonathandturner He didn't update it..

[Doaxan]

rustc 1.19.0-nightly (e17a1227a 2017-05-12):

DEBUG:rls::server: Language Server Starting up
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: Message("missing field `experimental`"), line: 0, column: 0 }', /checkout/src/libcore/result.rs:859
stack backtrace:
   0:     0x7fe5ce44a923 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::h0e14f963e590228b
                               at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x7fe5ce445296 - std::sys_common::backtrace::_print::h27334d67e47d33d3
                               at /checkout/src/libstd/sys_common/backtrace.rs:71
   2:     0x7fe5ce4591f4 - std::panicking::default_hook::{{closure}}::h47b2a7bf24f9ec4b
                               at /checkout/src/libstd/sys_common/backtrace.rs:60
                               at /checkout/src/libstd/panicking.rs:355
   3:     0x7fe5ce458dbb - std::panicking::default_hook::h96a38c23a922ad21
                               at /checkout/src/libstd/panicking.rs:371
   4:     0x7fe5ce4596ab - std::panicking::rust_panic_with_hook::h2e0c66f95442aa5e
                               at /checkout/src/libstd/panicking.rs:549
   5:     0x7fe5ce459534 - std::panicking::begin_panic::h2bd4bbc032e2aa18
                               at /checkout/src/libstd/panicking.rs:511
   6:     0x7fe5ce4594b9 - std::panicking::begin_panic_fmt::hbb7f6691241b0d12
                               at /checkout/src/libstd/panicking.rs:495
   7:     0x7fe5ce459447 - rust_begin_unwind
                               at /checkout/src/libstd/panicking.rs:471
   8:     0x7fe5ce495f5d - core::panicking::panic_fmt::h8b3b4367ded67bbc
                               at /checkout/src/libcore/panicking.rs:69
   9:     0x55afe293caa6 - core::result::unwrap_failed::h6c21d0e55176b173
  10:     0x55afe29efa32 - rls::server::parse_message::h2edfbf3ee47a05c4
  11:     0x55afe29cf9f6 - rls::server::MessageReader::parsed_message::hae39de626507d158
  12:     0x55afe29c1ab7 - rls::server::LsService::run::h8cfa22a637b384bd
  13:     0x55afe29d1dc1 - rls::main::hb030a9ee8c1a2205
  14:     0x7fe5ce46280a - __rust_maybe_catch_panic
                               at /checkout/src/libpanic_unwind/lib.rs:98
  15:     0x7fe5ce45a408 - std::rt::lang_start::h383c8992c0d0ccc3
                               at /checkout/src/libstd/panicking.rs:433
                               at /checkout/src/libstd/panic.rs:361
                               at /checkout/src/libstd/rt.rs:56
  16:     0x7fe5cd6c35fd - __libc_start_main
  17:     0x55afe28bbd68 - <unknown>
[Error - 9:26:19 AM] Connection to server got closed. Server will not be restarted.

[Enet4]

The error "missing field experimental" should no longer happen with the fix in #313. It might be that it simply hasn't landed in Nightly yet. How can we verify this?

[chengyuhui]

I think we need a pull request..... I am not seeing any RLS-related commits, only rust-lang/rust@1ffa6b731e which happened few days ago...

[Enet4]

Ah, so we need to update the rls submodule in the Rust repository? Allow me to propose another RLS update then.

[chengyuhui]

Yeah, we need a pull request.

[martinschleiss]

I just updated to the newest version, now I'm getting:

Running target/debug/rls
thread 'main' panicked at 'called Result::unwrap() on an Err value: ErrorImpl { code: Message("missing field rootUri"), line: 0, column: 0 }', /checkout/src/libcore/result.rs:859
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at /checkout/src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/sys_common/backtrace.rs:60
at /checkout/src/libstd/panicking.rs:355
3: std::panicking::default_hook
at /checkout/src/libstd/panicking.rs:371
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:549
5: std::panicking::begin_panic
at /checkout/src/libstd/panicking.rs:511
6: std::panicking::begin_panic_fmt
at /checkout/src/libstd/panicking.rs:495
7: rust_begin_unwind
at /checkout/src/libstd/panicking.rs:471
8: core::panicking::panic_fmt
at /checkout/src/libcore/panicking.rs:69
9: core::result::unwrap_failed
at /checkout/src/libcore/macros.rs:29
10: >::unwrap
at /checkout/src/libcore/result.rs:737
11: rls::server::parse_message
at src/server.rs:135
12: rls::server::MessageReader::parsed_message::{{closure}}
at src/server.rs:400
13: >::map
at /checkout/src/libcore/option.rs:392
14: rls::server::MessageReader::parsed_message
at src/server.rs:400
15: rls::server::LsService::handle_message
at src/server.rs:327
16: rls::server::LsService::run
at src/server.rs:219
17: rls::server::run_server
at src/server.rs:533
18: rls::main
at src/main.rs:72
19: __rust_maybe_catch_panic
at /checkout/src/libpanic_unwind/lib.rs:98
20: std::rt::lang_start
at /checkout/src/libstd/panicking.rs:433
at /checkout/src/libstd/panic.rs:361
at /checkout/src/libstd/rt.rs:56
21: main
22: __libc_start_main
23: _start
[Error - 2:04:53 PM] Connection to server got closed. Server will not be restarted.

[Enet4]

@martinschleiss I'm afraid I cannot reproduce that in my system. It's also definitely not the same issue as those observed before. What language server consumer have you used?

[martinschleiss]

I'm using jonathan's vscode extension

[chengyuhui]

It shouldn't happen according to the code...

[Enet4]

The "rootUri" field is clearly optional. I would advise you to make sure that you have built from the latest position in the master branch.

[Marwes]

A small test shows that rootUri does not seem to act as an optional field. Presumably the with attribute is messing it up. Will see what I can do

    #[derive(Deserialize)]
    pub struct Params {
        #[serde(with="option_url")]
        #[serde(rename="rootUri")]
        pub root_uri: Option<Url>,

    }

    #[test]
    fn t() {
        let deserialized: Params = serde_json::from_str("{}").unwrap();
    }

[Enet4]

This is still odd though. I can't see why the implementation of option_uri::deserialize is incompatible with an empty field.

[Marwes]

@Enet4 When a deserializer encounters a missing field it usually calls a missing_field function which requires a Deserialize bound on the field but this is not the case for all fields that has a with attribute (as is the case here). So instead it fails immediately, see https://github.com/serde-rs/serde/issues/259.

[martinschleiss]

Ok, it's working again. Thanks!

[nrc]

Leaving open until we update the RLS submodule in Rust

[rnleach]

I just updated to nightly 826d8f385 2017-05-13 and it still hasn't landed in nightly.

[FaultyRAM]

@rnleach PR hasn't been merged yet, keep an eye on https://github.com/rust-lang/rust/pull/41969

[Geobert]

Hi, I'm new to Rust, is there anykind of respin in nightly to push critical fixes quicker?

[light4]

@Geobert You can add date to nightly, just like this:

rustup override set nightly-2017-05-10
rustup component add rls --toolchain nightly-2017-05-10
rustup component add rust-analysis --toolchain nightly-2017-05-10
rustup component add rust-src --toolchain nightly-2017-05-10

[jntrnr]

@Geobert - To my knowledge, the current infrastructure only lets us spin at night.

[rnleach]

@jonathandturner at night in what country/timezone? ;)

[jntrnr]

@rnleach - AIUI they roll out at midnight GMT (UTC+0)

[Enet4]

rustc 1.19.0-nightly (386b0b9d3 2017-05-14) is in! We're finally done here. :)

[nrc]

@Enet4 \o/ Have you tested that the RLS now runs without crashes?

[Enet4]

@nrc I tested it on my machine and it all worked well. Still, it wouldn't hurt to have a few more people try it out before we close.

[nrc]

Awesome, thanks @Enet4 !

[daniel-dsouza]

@Enet4 the RLS no longer crashes for me on rustc 1.19.0-nightly (386b0b9d3 2017-05-14) using the vscode-rust extension

[josephlr]

RLS is still crashing for me on any project (although it takes longer than before), see rust-lang-nursery/rls-vscode#67. I'm on rustc 1.20.0-nightly (f590a44ce 2017-06-27) (nightly-x86_64-apple-darwin).

[zmanian]

rls --version will give you commit hash and date for the rls version. You'll see it is currently from 6/20. I think the fix for this was merged on 6/24. @nrc mentioned deploying > 6/20 to rustup in the next couple days.

[josephlr]

Thanks @zmanian, I had gotten rustc 2017-06-27 and rls 2017-06-20 switched. Everything's great after rebuilding from source!