I keep getting "[ERROR] The Rust Language Service server crashed 5 times in the last 3 minutes. The server will not be restarted." Is there any way I can get output from the server to see what might be happening?
I get this after opening this project, a reddit user pointed to this one as well.
Try setting this variable to true. https://github.com/jonathandturner/rls_vscode/blob/master/src/extension.ts#L10
Then you should see something in the output view.
@jonasbb that doesn't seem to do anything. I get the same error several seconds after the second VS Code instance opens. Nothing is printed in the terminal or the debug console of the first VS Code. Is it perhaps "remembering" the crashes from the previous launch?
On Wed, Jan 18, 2017 at 12:48 PM, Jonas Bushart notifications@github.com
wrote:
Try setting this variable to true. https://github.com/
jonathandturner/rls_vscode/blob/master/src/extension.ts#L10
Then you should see something in the output view.β
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273548017,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxoYZzoDM3N17xGXRUGKoV_pG4yRks5rTlBsgaJpZM4LnETY
.
I see it when trying to do anything in lightning as well.
@durka It would print something to the second instance, not the first one. In the output view on the right hand side there is a drop down field. Does it contain "Rust Language Service" (2nd instance)?
I'm not sure which dropdown you mean. Here's the window:

Do you mean the ... button in the top right? That only contains "Show opened editors" (which is only lib.rs) and "Close all". Selecting "View->Debug console" from the menu, it is also empty.
@durka - what happens if you run the rls by hand with a cargo run?
I was able to open cellsplit and libbig working on my side, so I wonder if these issues are coming from somewhere related.
I'm using:
rustc 1.16.0-nightly (ff591b6dc 2017-01-15)
Maybe there's a rustc mismatch?
You can get a little better debugging by setting:
let DEV_MODE = true;
In the VSCode plugin, on line 10 in extension.ts.
rls seems to run fine when I do cargo run --release. But nothing is
printed in the console. I guess VS Code is trying to run its own instance?
I have rustc 1.16.0-nightly (4ce7accaa 2017-01-17). I'll try downgrading.
I tried that DEV_MODE setting as suggested above but it had no effect, even
after restarting both instances of VS Code. Maybe I need to convince VS
Code to recompile the plugin somehow?
On Wed, Jan 18, 2017 at 1:54 PM, Jonathan Turner notifications@github.com
wrote:
@durka https://github.com/durka - what happens if you run the rls by
hand with a cargo run?I was able to open cellsplit and libbig working on my side, so I wonder if
these issues are coming from somewhere related.I'm using:
rustc 1.16.0-nightly (ff591b6dc 2017-01-15)
Maybe there's a rustc mismatch?
You can get a little better debugging by setting:
let DEV_MODE = true;
In the VSCode plugin, on line 10 in extension.ts.
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273565995,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxL5T2Js9GrWpR8mW5DcpIFihp_xks5rTl_hgaJpZM4LnETY
.
Another note: I'm on OSX 10.9.5.
On Wed, Jan 18, 2017 at 2:01 PM, Alex Burka durka42@gmail.com wrote:
rls seems to run fine when I do
cargo run --release. But nothing is
printed in the console. I guess VS Code is trying to run its own instance?I have
rustc 1.16.0-nightly (4ce7accaa 2017-01-17). I'll try downgrading.I tried that DEV_MODE setting as suggested above but it had no effect,
even after restarting both instances of VS Code. Maybe I need to convince
VS Code to recompile the plugin somehow?On Wed, Jan 18, 2017 at 1:54 PM, Jonathan Turner <[email protected]
wrote:
@durka https://github.com/durka - what happens if you run the rls by
hand with a cargo run?I was able to open cellsplit and libbig working on my side, so I wonder
if these issues are coming from somewhere related.I'm using:
rustc 1.16.0-nightly (ff591b6dc 2017-01-15)
Maybe there's a rustc mismatch?
You can get a little better debugging by setting:
let DEV_MODE = true;
In the VSCode plugin, on line 10 in extension.ts.
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273565995,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxL5T2Js9GrWpR8mW5DcpIFihp_xks5rTl_hgaJpZM4LnETY
.
@durka - yeah, it doesn't print anything out when it starts up, but if it's not crashing immediately that's at least something π
VS Code compiles the plugin when you hit debug. The TypeScript just compiles fast enough that it doesn't seem to be doing anything before it starts the second VSCode instance.
RLS uses log and env_logger. If you add RUST_LOG=info to your environment and restart VSCode in that environment, you'll see some of the debug info. Maybe that'll be enough to tip us off to what's going wrong.
Not sure if the OS X version makes a difference. I'm guessing not so long as stuff like node is up to date.
(I'm on macOS 10.12.2)
Even running RUST_LOG=info code . in the rls_vscode directory, there is
no output. I'm thinking VS Code doesn't even get as far as running RLS.
On Wed, Jan 18, 2017 at 2:09 PM, Jonathan Turner notifications@github.com
wrote:
Not sure if the OS X version makes a difference. I'm guessing not so long
as stuff like node is up to date.(I'm on macOS 10.12.2)
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273570089,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n940qqS0B2fbHhKPrkTD2mdeEWJaks5rTmNlgaJpZM4LnETY
.
I did finally get some output in the VS Code debug window. Here it is:
'/Applications/Visual Studio Code.app/Contents/MacOS/Electron'
--debugBrkPluginHost=33047
--extensionDevelopmentPath=/Users/alex/Programming/rust/rls_vscode
MANY messages are being SEND FROM the extension host!
SEND during 1sec: message_count=507, total_len=507
MANY messages are being SEND FROM the extension host!
SEND during 1sec: message_count=661, total_len=661
MANY messages are being SEND FROM the extension host!
SEND during 1sec: message_count=496, total_len=496
MANY messages are being SEND FROM the extension host!
SEND during 1sec: message_count=635, total_len=635
MANY messages are being SEND FROM the extension host!
SEND during 1sec: message_count=488, total_len=488
MANY messages are being SEND FROM the extension host!
SEND during 1sec: message_count=318, total_len=318
On Wed, Jan 18, 2017 at 2:21 PM, Alex Burka durka42@gmail.com wrote:
Even running
RUST_LOG=info code .in the rls_vscode directory, there is
no output. I'm thinking VS Code doesn't even get as far as running RLS.On Wed, Jan 18, 2017 at 2:09 PM, Jonathan Turner <[email protected]
wrote:
Not sure if the OS X version makes a difference. I'm guessing not so long
as stuff like node is up to date.(I'm on macOS 10.12.2)
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273570089,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n940qqS0B2fbHhKPrkTD2mdeEWJaks5rTmNlgaJpZM4LnETY
.
@durka Is there any text in the Output window of the second VS Code instance? In the menu View > Output
MANY messages are being SEND FROM the extension host! SEND during 1sec: message_count=318, total_len=318
I haven't seen this before, but it sounds a bit ominous. Is this with the logger turned on?
@durka
Just to be doubly sure the RLS works, does it work for any other projects? Is it just this one that's giving you trouble.
(You can also run the unit tests on the RLS with RUST_TEST_THREADS=1 cargo test in the rls directory if you're wondering if the rls is working)
All tests pass.
I tried opening an empty project (cargo new empty). I added the following
text to src/lib.rs:
fn foo() {
let x = 42;
}
and then got the crash message, but I don't know if it was related to the
entered code or not.
On Wed, Jan 18, 2017 at 2:46 PM, Jonathan Turner notifications@github.com
wrote:
@durka https://github.com/durka
Just to be doubly sure the RLS works, does it work for any other projects?
Is it just this one that's giving you trouble.(You can also run the unit tests on the RLS with RUST_TEST_THREADS=1
cargo test in the rls directory if you're wondering if the rls is working)β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273580688,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n7ewMRwVx5e8zq2Q_ScaWDhU6Jelks5rTmwwgaJpZM4LnETY
.
Did you set the RLS_ROOT to point to the rls checkout, by chance? I was just thinking that you might see crashes like that if it was trying to run rls but not going down the cargo run path.
I sure did! I think the problem may be related to rustc version after all
-- I had set the override in the rls directory, but the extension ignores
that since it runs cargo from the rls_vscode directory. After setting the
override there as well, my CPU has been pegged for several minutes and I
see it is compiling rls. I need to have my computer responsive for the next
few hours but I'll report back later when I have time to let it run.
On Wed, Jan 18, 2017 at 3:43 PM, Jonathan Turner notifications@github.com
wrote:
Did you set the RLS_ROOT to point to the rls checkout, by chance? I was
just thinking that you might see crashes like that if it was trying to run
rls but not going down the cargo run path.β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273595699,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n_rMRoNQZnH-UwmQkgOvS1sow3Mkks5rTnlVgaJpZM4LnETY
.
huzzah! I'm crossing my fingers that was it. Definitely let us know.
That may have been it? I pinned the rls_vscode directory and ran cargo build --manifest-path=$RLS_ROOT/Cargo.toml --release there (so I could see the progress in terminal instead of having VS Code lock up the whole machine). Then I re-ran the extension in VS Code and it immediately stops at line 179 of node_modules/vscode-jsonrpc/lib/messageReader.js:
throw new Error('Header must provide a Content-Length property.');
Should I open a separate issue for that?
That is a generic error which basically just means that something other than the LSP data got written to stdout. Did you add a println or anything to debug?
The only thing I did is set DEV_MODE to true.
On Thu, Jan 19, 2017 at 2:34 PM, Nick Cameron notifications@github.com
wrote:
That is a generic error which basically just means that something other
than the LSP data got written to stdout. Did you add a println or anything
to debug?β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273875063,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxrZoeWBQaOyttGYyICmpaHF_dJGks5rT7qxgaJpZM4LnETY
.
@durka do you have RUST_LOG set to a value by chance? I noticed yesterday that this was enough to cause the 'Header must provide a Content-Length property.' issue. Hopefully, we can fix that.
But yes, please file a separate issue and we'll track that down.
Ah yes, I set RUST_LOG=info as suggested by a comment above. It seems to be
stuck now, though... I've turned it off but VS Code still thinks it's on.
There is way too much caching!
On Thu, Jan 19, 2017 at 9:17 PM, Jonathan Turner notifications@github.com
wrote:
@durka https://github.com/durka do you have RUST_LOG set to a value by
chance? I noticed yesterday that this was enough to cause the 'Header
must provide a Content-Length property.' issue. Hopefully, we can fix
that.But yes, please file a separate issue and we'll track that down.
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273958882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxTaf84JFg9FIw4s8THIpQNTWyNlks5rUBk5gaJpZM4LnETY
.
I added process.env.RUST_LOG = ""; to the activate function and it works
now.
On Fri, Jan 20, 2017 at 12:43 AM, Alex Burka durka42@gmail.com wrote:
Ah yes, I set RUST_LOG=info as suggested by a comment above. It seems to
be stuck now, though... I've turned it off but VS Code still thinks it's
on. There is way too much caching!On Thu, Jan 19, 2017 at 9:17 PM, Jonathan Turner <[email protected]
wrote:
@durka https://github.com/durka do you have RUST_LOG set to a value by
chance? I noticed yesterday that this was enough to cause the 'Header
must provide a Content-Length property.' issue. Hopefully, we can fix
that.But yes, please file a separate issue and we'll track that down.
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rls_vscode/issues/26#issuecomment-273958882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxTaf84JFg9FIw4s8THIpQNTWyNlks5rUBk5gaJpZM4LnETY
.
@durka - should we close this one? It feels like there are a few things we could do to improve the documentation.
Actually, if you can remember them, can you list the things you needed to do to get it to work so we can add it to the docs and help other people who hit some of the same issues?
@jonathandturner the two keys were (1) make sure a rustup override is set in the rls_vscode dir and (2) make sure RUST_LOG is not set (which required modifying the code because I don't know how to clear VS Code's cache of such things).
Hi. Today after rustup update I've got the same issue. In the output window I got the following message:
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 - 12:16:48 AM] Connection to server got closed. Server will not be restarted.
Is there a fix for this?
This is probably https://github.com/rust-lang-nursery/rls/issues/312, we are currently waiting for the fix to land in Rustup. If you build from source and use the latest nightly Rust, this should be fixed already.
Seems like the first issue is resolved now and the later one probably also
Hi everyone. I see that this issue is closed since June, but I am getting the "The Rust Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted." message all the time.
I am running only nightly at this time (the stable toolchain is not even installed). I have checked rust-lang-nursery/rls#312 and I found no hint of what may be going on.
Environment: windows running vscode 1.16.1, rls plugin version 0.2.3 and rustup show gives:
_Default host: x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc (default)
rustc 1.22.0-nightly (01c65cb15 2017-09-20)_
What did I miss?
Thanks,
Daniel
What is the output of _rustup run nightly rls --version_?
Do you initialize vscode in a folder with Cargo.toml file and ordinary
Cargo project?
(Hope the formatting isn't screwed, replying via email)
On Fri, 22 Sep 2017 at 20:17, Daniel AraΓΊjo Miranda <
[email protected]> wrote:
Hi everyone. I see that this issue is closed since June, but I am getting
the "The Rust Language Server server crashed 5 times in the last 3 minutes.
The server will not be restarted." message all the time.I am running only nightly at this time (the stable toolchain is not even
installed). I have checked rust-lang-nursery/rls#312
https://github.com/rust-lang-nursery/rls/issues/312 and I found no hint
of what may be going on.Environment: windows running vscode 1.16.1, rls plugin version 0.2.3 and
rustup show gives:Default host: x86_64-pc-windows-msvc nightly-x86_64-pc-windows-msvc
(default) rustc 1.22.0-nightly (01c65cb15 2017-09-20)What did I miss?
Thanks,
Danielβ
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/rls-vscode/issues/26#issuecomment-331522853,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC8y3fbR5-MomipHI9U0Irekwcsskg65ks5sk_nKgaJpZM4LnETY
.
rustup run nightly rls --version
rls-preview 0.122.0-nightly (7221e38 2017-09-14)
Yes, I started the project with "cargo new myprojectname --bin", and there is a Cargo.toml file.
The actual folder used by vscode is the project root (Cargo.toml, Cargo.lock, src/, target/, .gitignore and .vscode/ are at the root of the EXPLORER tree).
@mirandadam have a look at https://github.com/rust-lang-nursery/rls/blob/master/debugging.md, you should try enabling logging to try and get some more data about what is happening.
@nrc and @Xanewok, thanks for the replies. Will get more data tomorrow.
Still couldn't get back to working on this. I shouldn't have commited to a 'deadline' on monday, sorry. Will provide the data when I have it.
@mirandadam have a look at https://github.com/rust-lang-nursery/rls/blob/master/debugging.md, you should try enabling logging to try and get some more data about what is happening.
I enabled RLS logging, and it generated 5 new rls###.log files, but they're all empty.
rls --version works as expected from the vs code terminal, but the extensions continues to throw rather cryptic errors. Please suggest any other troubleshooting / diagnostic steps.