Rls: Panic: 'missing key in compiler_jobs'

Created on 22 Mar 2018  路  11Comments  路  Source: rust-lang/rls

Getting a crash when using rls with https://github.com/autozimu/LanguageClient-neovim/. Didn't have backtrace enabled at the time of the crash but I have enabled it now and will update this issue if it re-appears

error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `)`
 --> bogofile:7:70
  |
7 |                             != module::Enum::Default)
  |                                                                      ^

error: expected expression, found `<eof>`
 --> bogofile:8:29
  |
8 |                             
  |                             ^

error: expected one of `,`, `.`, `;`, `<`, `?`, `break`, `const`, `continue`, `enum`, `extern`, `false`, `fn`, `for`, `if`, `impl`, `let`, `loop`, `match`, `mod`, `move`, `pub`, `return`, `static`, `struct`, `trait`, `true`, `type`, `unsafe`, `use`, `while`, `}`, or an operator, found `<eof>`
 --> bogofile:8:29
  |
8 |                             
  |                             ^

thread 'request-worker-4' panicked at 'assertion failed: structmatch.mtype == core::MatchType::Struct', /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/racer-2.0.12/src/racer/typeinf.rs:220:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<unnamed>' panicked at 'missing key in compiler_jobs', libcore/option.rs:916:5
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', libcore/result.rs:945:5

Version: rls-preview 0.126.0-nightly (567fb6d 2018-03-17)
OS: OSX

bug racer

All 11 comments

I believe this is a racer issue, probably dependent on specifically how the file is being edited

It's definitely a racer bug and I'm really interested in this problem.

@Marwes
Can you please note the file name you were editing, if you remember it?

@kngwyu I believe it was src/config/mod.rs

@Marwes
Thanks, but I forgot asking the crate name you were working at.
Can you please note it?

The name of the crate is api but it is proprietary so I am afraid I can't divulge anything more than that.

Oh, so I'm sorry it's difficult to debug...
Anyway, now I know there's some bug around racer's get_struct_field_type, so thank you very much for reporting.

I think that this consistently happens for me - If you need my sources tell me and I'll upload them.
EDIT: another panic, with the message "out of order or duplicate change"

I'll try to make this happen with RUST_BACKTRACE=1, but here is the output for now:

thread '<unnamed>' panicked at 'missing key in compiler_jobs', libcore/option.rs:916:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', libcore/result.rs:945:5
[Info  - 12:56:51 AM] Connection to server got closed. Server will restart.
thread 'main' panicked at 'Out of order or duplicate change', tools/rls/src/actions/mod.rs:270:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
[Info  - 12:56:51 AM] Connection to server got closed. Server will restart.
[Error - 12:56:51 AM] Request textDocument/codeAction failed.
Error: Connection got disposed.
    at Object.dispose (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-jsonrpc/lib/main.js:825:25)
    at Object.dispose (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-languageclient/lib/client.js:57:35)
    at LanguageClient.handleConnectionClosed (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-languageclient/lib/client.js:1954:42)
    at LanguageClient.handleConnectionClosed (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-languageclient/lib/main.js:126:15)
    at closeHandler (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-languageclient/lib/client.js:1941:18)
    at CallbackList.invoke (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-jsonrpc/lib/events.js:71:39)
    at Emitter.fire (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-jsonrpc/lib/events.js:135:36)
    at closeHandler (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-jsonrpc/lib/main.js:221:26)
    at CallbackList.invoke (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-jsonrpc/lib/events.js:71:39)
    at Emitter.fire (/home/noam/.vscode/extensions/rust-lang.rust-0.4.1/node_modules/vscode-jsonrpc/lib/events.js:135:36)
thread 'main' panicked at 'Out of order or duplicate change', tools/rls/src/actions/mod.rs:270:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
[Error - 12:56:52 AM] Connection to server is erroring. Shutting down server.
[Error - 12:56:52 AM] Connection to server is erroring. Shutting down server.
[Error - 12:56:52 AM] Connection to server is erroring. Shutting down server.

With traceback:

thread '<unnamed>' panicked at 'missing key in compiler_jobs', libcore/option.rs:916:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:403
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:349
   7: rust_begin_unwind
             at libstd/panicking.rs:325
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:72
   9: core::option::expect_failed
             at libcore/option.rs:916
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  12: rls::build::plan::Plan::prepare_work
  13: rls::build::BuildQueue::run_thread
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:403
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:349
   7: rust_begin_unwind
             at libstd/panicking.rs:325
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:72
   9: core::result::unwrap_failed
  10: rls::build::BuildQueue::request_build
  11: rls::actions::InitActionContext::build_current_project
  12: rls::actions::notifications::<impl rls::server::message::BlockingNotificationAction for languageserver_types::notification::DidChangeTextDocument>::handle
  13: rls::server::run_server
  14: rls::main
  15: std::rt::lang_start::{{closure}}
  16: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:306
  17: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  18: std::rt::lang_start_internal
             at libstd/panicking.rs:285
             at libstd/panic.rs:361
             at libstd/rt.rs:58
  19: main
  20: __libc_start_main
  21: <unknown>
[Info  - 1:15:05 AM] Connection to server got closed. Server will restart.

Another traceback, with a possibly unrelated error ('Out of order or duplicate change'):

thread 'main' panicked at 'Out of order or duplicate change', tools/rls/src/actions/mod.rs:270:13
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:403
   6: std::panicking::begin_panic
   7: rls::actions::InitActionContext::check_change_version
   8: rls::actions::notifications::<impl rls::server::message::BlockingNotificationAction for languageserver_types::notification::DidChangeTextDocument>::handle
   9: rls::server::run_server
  10: rls::main
  11: std::rt::lang_start::{{closure}}
  12: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:306
  13: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  14: std::rt::lang_start_internal
             at libstd/panicking.rs:285
             at libstd/panic.rs:361
             at libstd/rt.rs:58
  15: main
  16: __libc_start_main
  17: <unknown>

I get the same(?) error. Strangely there is no backtrace even with RUST_BACKTRACE=1:

thread '<unnamed>' panicked at 'missing key in compiler_jobs', libcore\option.rs:916:5
stack backtrace:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', libcore\result.rs:945:5
stack backtrace:
   0: <std::collections::hash::map::DefaultHasher as core::fmt::Debug>::fmt
   1: std::sys::windows::c::TryAcquireSRWLockShared
   2: std::panicking::take_hook
   3: std::panicking::take_hook
   4: rustc::ty::maps::on_disk_cache::__ty_decoder_impl::<impl serialize::serialize::Decoder for rustc::ty::maps::on_disk_cache::CacheDecoder<'a, 'tcx, 'x>>::read_str
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: std::panicking::update_panic_count
  17: _rust_maybe_catch_panic
  18: std::rt::lang_start_internal
  19: <unknown>
  20: git_libgit2_version
  21: BaseThreadInitThunk
  22: RtlUserThreadStart
[Info  - 15:05:14] Connection to server got closed. Server will restart.
[Error - 15:05:14] Request textDocument/codeAction failed.
Error: Connection got disposed.
    at Object.dispose (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-jsonrpc\lib\main.js:825:25)
    at Object.dispose (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-languageclient\lib\client.js:57:35)
    at LanguageClient.handleConnectionClosed (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-languageclient\lib\client.js:1954:42)
    at LanguageClient.handleConnectionClosed (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-languageclient\lib\main.js:126:15)
    at closeHandler (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-languageclient\lib\client.js:1941:18)
    at CallbackList.invoke (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-jsonrpc\lib\events.js:71:39)
    at Emitter.fire (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-jsonrpc\lib\events.js:135:36)
    at closeHandler (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-jsonrpc\lib\main.js:221:26)
    at CallbackList.invoke (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-jsonrpc\lib\events.js:71:39)
    at Emitter.fire (C:\Users\dthul\.vscode\extensions\rust-lang.rust-0.4.1\node_modules\vscode-jsonrpc\lib\events.js:135:36)

Edit: rls-preview 0.126.0-nightly (f5a0c91 2018-03-26), VSCode RLS plugin 0.4.1

This should be fixed with the latest nightly version of RLS.

@nrc the latest nightly does seem much improved: I was getting this issue constantly, and since upgrading, it hasn't happened once.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

benmarten picture benmarten  路  3Comments

ZoeyR picture ZoeyR  路  3Comments

sunshowers picture sunshowers  路  5Comments

parkovski picture parkovski  路  3Comments

wagnerf42 picture wagnerf42  路  3Comments