Ubuntu: thread '<unknown>' has overflowed its stack

[azriel91]

Hiya, in a similar nature to #838, RLS crashes when I run it on one of my projects. Unfortunately the source is closed so there's no easy steps to reproduce, and I haven't managed to narrow down which crate(s) the analysis crashes on.

Info:

• Ubuntu 18.04
• rustc 1.30.0-nightly (1c2e17f4e 2018-09-04)
• rls-preview 0.130.5-nightly (cf6358a 2018-09-04)

$ rls --cli
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
        ),
        type_definition_provider: None,
        implementation_provider: Some(
            Simple(
                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: Some(
            CodeLensOptions {
                resolve_provider: Some(
                    false
                )
            }
        ),
        document_formatting_provider: Some(
            true
        ),
        document_range_formatting_provider: Some(
            false
        ),
        document_on_type_formatting_provider: None,
        rename_provider: Some(
            true
        ),
        color_provider: None,
        execute_command_provider: Some(
            ExecuteCommandOptions {
                commands: [
                    "rls.applySuggestion-11897",
                    "rls.deglobImports-11897"
                ]
            }
        )
    }
}

{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_1","title":"Building"}}
... heaps of messages similar to the one below, with different crate names  ...
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_1","message":"map_model","title":"Building"}}

thread '<unknown>' has overflowed its stack
fatal runtime error: stack overflow
[1]    11897 abort (core dumped)  rls --cli

Is there a way to get more useful information? export RUST_BACKTRACE=1 doesn't help

[azriel91]

Not sure if this is useful info. I tried:

• ulimit -s 32768 (default is ulimit -s 8192)
• export RUST_MIN_STACK=8388608

before running rls --cli on the workspace, and neither worked. See SO and rust doc.

Then I narrowed down a test function that stack overflowed when running cargo test. After #[ignore]-ing the test, running rls --cli on that crate itself worked, and then rls --cli on the whole project worked. Un#[ignore]-ing the test and running rls --cli still works, I haven't removed the target/rls directory yet to retry to see if it fails. This is a red herring, it's probably a non-related stack overflow

[azriel91]

Not sure how to reproduce this, I guess if it comes up again I'll reopen it.

[Amanieu]

I have managed to reproduce this. I got this backtrace from gdb when the stack overflow happens:

#0  0x00007ffff65b1e0d in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#1  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#2  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#3  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#4  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#5  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#6  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#7  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#8  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#9  0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#10 0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#11 0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so
#12 0x00007ffff65b2176 in rustc::dep_graph::graph::DepGraph::try_mark_green () from /home/amanieu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc-d3bd6c4269324849.so

$ rls --version
rls-preview 0.130.5-nightly (2b21611 2018-09-15)

[azriel91]

Hiya, is the project that it happens on public? (so others can clone and reproduce it, to verify that it doesn't happen when it's fixed)

[Amanieu]

Unfortunately the project is also closed. And I deleted my target/rls directory, which fixed the problem, but means that I can't reproduce the bug anymore.

I just thought the backtrace would help narrow the problem down a bit.

[Diggsey]

I ran into the same issue, again unfortunately with a closed source project 😦

[Diggsey]

Also, deleting the target/rls directory does not fix the problem for me.

edit: I found that the project had an unnecessarily high recursion limit, reducing it to #![recursion_limit = "512"] fixed the problem.

edit2: So unfortunately "1024" is needed to build the project -.-

[namiwang]

@azriel91 Hi! I've just encountered with the same issue and the repo is public, do you think it will help?

[azriel91]

Yeap -- that way it can be investigated.
Good idea to also specify the Rust version and RLS version as well – I haven't hit this issue for a while on my computers.

[athei]

It seems to happen with very large enums. I managed to come up with a minimal example that always crashes the stable rls 1.32.0: https://github.com/athei/rls_crash .The crash does not happen with the current nightly (00aae71f5 2019-02-25).

rls --cli
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
        ),
        type_definition_provider: None,
        implementation_provider: Some(
            Simple(
                true
            )
        ),
        references_provider: Some(
            true
        ),
        document_highlight_provider: Some(
            true
        ),
        document_symbol_provider: Some(
            true
        ),
        workspace_symbol_provider: Some(
            true
        ),
        code_action_provider: Some(
            Simple(
                true
            )
        ),
        code_lens_provider: Some(
            CodeLensOptions {
                resolve_provider: Some(
                    false
                )
            }
        ),
        document_formatting_provider: Some(
            true
        ),
        document_range_formatting_provider: Some(
            false
        ),
        document_on_type_formatting_provider: None,
        rename_provider: Some(
            Simple(
                true
            )
        ),
        color_provider: None,
        folding_range_provider: None,
        execute_command_provider: Some(
            ExecuteCommandOptions {
                commands: [
                    "rls.applySuggestion-9368",
                    "rls.deglobImports-9368"
                ]
            }
        ),
        workspace: None
    }
}
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_1","title":"Building"}}
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_1","message":"rls_crash cfg(test)","title":"Building"}}
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_1","message":"rls_crash","title":"Building"}}

thread '<unknown>' has overflowed its stack
fatal runtime error: stack overflow
[1]    9368 abort      rls --cli

[Xanewok]

... rustc::dep_graph::graph::DepGraph::try_mark_green () ...

This looks like an infinite recursion in the algorithm behind incremental compilation in rustc. Which is weird - I'd expect it to fail when using regular compilation?

I tried the rls_crash with the most recent 1.33 stable toolchain and it looks like the crash is gone 🎉

I'll close this, but please reopen if the issue still persists!

[athei]

rustc worked fine for me. I switched to the new stable 1.33 and the crash is gone 🎉