stderr thread 'main' has overflowed its stack

[dannyfritz]

I'm using ide-rust with a project using glium and following the tutorials. https://github.com/glium/glium/tree/master/book

The linter doesn't seem to be working when I'm in this glium project. When I enable logging, I get logger.ts:19 Rust (RLS) stderr thread 'main' has overflowed its stack in the console.

[alexheretic]

Thanks, we should report this upstream as it's an rls panic. I assume you're using the latest nightly-2018-04-18?

I had a quick look to see if I could reproduce just using the main glium repo, with all_targets = true to compile the examples, but it seems to work fine for me.

Does this happen for you on other, public, repos? Or can you shove the offending code somewhere public for reproduction?

[dannyfritz]

Versions via rustup: (is there a better way to get the versions?)

λ rustup update
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: checking for self-updates

   stable-x86_64-pc-windows-msvc unchanged - rustc 1.25.0 (84203cac6 2018-03-25)
  nightly-x86_64-pc-windows-msvc unchanged - rustc 1.27.0-nightly (ac3c2288f 2018-04-18)

Tested it on some other Rust repos I had and it still works there. So here is the repo in question: https://github.com/dannyfritz/learn-glium

[dannyfritz]

I tested the repo with the official VSCode plugin and it seems to work there. I'm curious to see if you can reproduce the error on your computer with my repo or if it is something with my Atom.

[alexheretic]

I tested that repo and it works fine for me on linux. Can you try stripping down your atom to just ide-rust, language-rust & atom-ide-ui. I'll try setting up atom in windows and re-testing.

[dannyfritz]

With all packages except ide-rust, language-rust, and atom-ide-ui disabled I am still seeing the same thing. Is there a way to run Atom in --safe mode with these 3 packages installed?

Update: Lee Dohm on Atom Slack says there isn't a way to run in safe mode and have some packages enabled. He says a clean install or a moving around of startup scripts the best way to test that.

I did a clean install by changing my ATOM_HOME env var and I'm seeing the same results.

[alexheretic]

I had some trouble reproducing this on windows this as I'm getting other problems with the linker & atom.

[alexheretic]

Ok I've somewhat overcome the linker problems. I can reproduce this issue in atom and vscode. For vscode I just needed to enable "rust-client.logToFile": true to write the stderr to a log file and sure enough

thread 'main' has overflowed its stack

So I'd say it looks like an rls issue on windows. In fact try running rustup run nightly rls --cli on the cmd for this project. I get, eventually

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

[alexheretic]

I tested the repo with the official VSCode plugin and it seems to work there.

This seems strange as rls --cli doesn't even work for me. Can you double check @dannyfritz?

[dannyfritz]

I did get the same error when run on the command line with rustup run nightly rls --cli

https://lh3.googleusercontent.com/-LN9QZvRtjjg/WuICOio1p5I/AAAAAAABYlM/NMrSbGc9TnAuUKxH-Og0BYrj3OgwV8fzACHMYCw/s0/ConEmu64_2018-04-26_10-45-47.png

[dannyfritz]

Somehow, VSCode is able to do it. Don't know what black magic they are using, because it would seem to be the same RLS. https://github.com/rust-lang-nursery/rls-vscode

https://lh3.googleusercontent.com/-hU4osIRc6iA/WuIEKTvFK5I/AAAAAAABYlk/B2JDUslwAzkSj8AwVLUPhSbbaFpHNdEqwCHMYCw/s0/Code_2018-04-26_10-54-02.png

https://lh3.googleusercontent.com/-Ke0I7FZFUcs/WuIETYefomI/AAAAAAABYls/0F0fDqsykbYfliqp6F05p0y_FlVfkwR2ACHMYCw/s0/Code_2018-04-26_10-54-38.png

[alexheretic]

It happens on rls --cli which means it's client independant. I'd guess vscode works for you because it's actually using the stable toolchain. I believe it uses your rustup default, whereas atom you specify your choice in the settings.

Try setting atom to stable too to test the theory. Otherwise, we'll have to wait for a positive result from rust-lang/rls#838. Perhaps a future release will also fix this issue, it is nightly after all.

[dannyfritz]

Switched to stable and it works perfectly. Didn't know rls worked on stable. Thanks for your help with this.

Is it worth opening a issue in this repo to have it use the same rls channel as your current crate like VSCode might be doing?