RLS crashes in VSCode #312

rnleach · 2017-05-11T04:47:50Z

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.

sophiajt · 2017-05-11T08:54:47Z

rust-lang/rust#41900 just landed. With luck, this should roll out soon.

sophiajt · 2017-05-12T00:28:07Z

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

FaultyRAM · 2017-05-12T06:53:00Z

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 · 2017-05-12T09:31:51Z

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

Doaxan · 2017-05-12T14:11:28Z

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 · 2017-05-12T18:27:39Z

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/lsp-types#14 already.

Marwes · 2017-05-12T19:18:16Z

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

- update "languageserver-types" to 0.9.0 - modify initialization params to use `None` in experimental field of ClientCapabilities - change tests to consider an empty object in client capabilities

chengyuhui · 2017-05-13T00:10:01Z

When will the fix be available in rustup?

Enet4 · 2017-05-13T00:18:29Z

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 · 2017-05-13T01:13:30Z

It crashes...

rnleach · 2017-05-13T02:11:45Z

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 ***@***.***> 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 <#312 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJSF1pyn2eWpJ7oxo7gXX0LhFF-D3uiTks5r5QO8gaJpZM4NXgn3> .

sophiajt · 2017-05-13T04:37:07Z

@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 · 2017-05-13T05:24:30Z

@jonathandturner He didn't update it..

Doaxan · 2017-05-13T06:34:30Z

rustc 1.19.0-nightly (e17a122 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 · 2017-05-13T10:01:40Z

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 · 2017-05-13T11:10:24Z

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 · 2017-05-13T11:46:14Z

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

chengyuhui · 2017-05-13T12:01:03Z

Yeah, we need a pull request.

ghost · 2017-05-13T12:08:03Z

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: <core::result::Result<T, E>>::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: <core::option::Option>::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 · 2017-05-13T12:13:36Z

@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?

ghost · 2017-05-13T12:14:44Z

I'm using jonathan's vscode extension

chengyuhui · 2017-05-13T12:18:09Z

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

Enet4 · 2017-05-13T12:25:10Z

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.

Update RLS to solve serious crash As a follow-up to rust-lang/rls#312, this PR contains the fix to the latest experienced RLS crashes, which should hopefully reach the nightly release as soon as possible.

ghost · 2017-05-13T15:21:42Z

Ok, it's working again. Thanks!

Update RLS to solve serious crash As a follow-up to rust-lang/rls#312, this PR contains the fix to the latest experienced RLS crashes, which should hopefully reach the nightly release as soon as possible.

nrc · 2017-05-13T22:35:49Z

Leaving open until we update the RLS submodule in Rust

rnleach · 2017-05-14T04:44:30Z

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

FaultyRAM · 2017-05-14T05:45:28Z

@rnleach PR hasn't been merged yet, keep an eye on rust-lang/rust#41969

Update RLS to solve serious crash As a follow-up to rust-lang/rls#312, this PR contains the fix to the latest experienced RLS crashes, which should hopefully reach the nightly release as soon as possible.

Geobert · 2017-05-14T08:42:03Z

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

light4 · 2017-05-14T10:35:27Z

@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

sophiajt · 2017-05-14T21:03:09Z

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

rnleach · 2017-05-14T23:18:34Z

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

sophiajt · 2017-05-14T23:23:18Z

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

Enet4 · 2017-05-15T00:29:34Z

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

nrc · 2017-05-15T00:41:00Z

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

Enet4 · 2017-05-15T00:42:16Z

@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 · 2017-05-15T00:44:52Z

Awesome, thanks @Enet4 !

daniel-dsouza · 2017-05-15T00:54:36Z

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

josephlr · 2017-06-28T05:29:35Z

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

zmanian · 2017-06-28T05:35:05Z

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 · 2017-06-28T06:55:50Z

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

Enet4 mentioned this issue May 12, 2017

RLS crashes editor-rs/vscode-rust#229

Closed

Enet4 mentioned this issue May 12, 2017

Make ClientCapabilities.experimental field optional gluon-lang/lsp-types#15

Merged

Enet4 mentioned this issue May 12, 2017

Update language server types, making ClientCapabilities.experimental optional #313

Merged

nrc closed this as completed in #313 May 12, 2017

sophiajt reopened this May 13, 2017

Enet4 mentioned this issue May 13, 2017

Update RLS to solve serious crash rust-lang/rust#41969

Merged

nrc closed this as completed in 38ca9b7 May 13, 2017

nrc reopened this May 13, 2017

rnleach mentioned this issue May 14, 2017

vs-code error after successful installation on 1.19.0-nightly #316

Closed

cmyr mentioned this issue May 14, 2017

Constant error message under vscode-rust #315

Closed

nrc added the P-high label May 14, 2017

nrc mentioned this issue May 14, 2017

RLS server crashes rust-lang/vscode-rust#26

Closed

nrc closed this as completed May 15, 2017

josephlr mentioned this issue Jun 28, 2017

RLS Crashes rust-lang/vscode-rust#67

Closed

RLS crashes in VSCode #312

RLS crashes in VSCode #312

Comments

rnleach commented May 11, 2017

sophiajt commented May 11, 2017

sophiajt commented May 12, 2017

FaultyRAM commented May 12, 2017

zimond commented May 12, 2017

Doaxan commented May 12, 2017 • edited

Enet4 commented May 12, 2017 • edited

Marwes commented May 12, 2017

chengyuhui commented May 13, 2017

Enet4 commented May 13, 2017

chengyuhui commented May 13, 2017

rnleach commented May 13, 2017 via email

sophiajt commented May 13, 2017

chengyuhui commented May 13, 2017

Doaxan commented May 13, 2017

Enet4 commented May 13, 2017

chengyuhui commented May 13, 2017

Enet4 commented May 13, 2017

chengyuhui commented May 13, 2017

ghost commented May 13, 2017

Enet4 commented May 13, 2017

ghost commented May 13, 2017

chengyuhui commented May 13, 2017

Enet4 commented May 13, 2017

ghost commented May 13, 2017

nrc commented May 13, 2017

rnleach commented May 14, 2017

FaultyRAM commented May 14, 2017 • edited

Geobert commented May 14, 2017

light4 commented May 14, 2017

sophiajt commented May 14, 2017

rnleach commented May 14, 2017

sophiajt commented May 14, 2017

Enet4 commented May 15, 2017 • edited

nrc commented May 15, 2017

Enet4 commented May 15, 2017

nrc commented May 15, 2017

daniel-dsouza commented May 15, 2017

josephlr commented Jun 28, 2017

zmanian commented Jun 28, 2017

josephlr commented Jun 28, 2017

Doaxan commented May 12, 2017 •

edited

Enet4 commented May 12, 2017 •

edited

FaultyRAM commented May 14, 2017 •

edited

Enet4 commented May 15, 2017 •

edited