Stream: t-compiler/rust-analyzer

Topic: syntax ptr crash

std::Veetaha (Apr 07 2020 at 20:24, on Zulip):

This has been a long time I have been seeing this damn crash:

thread '<unnamed>' panicked at 'can't resolve local ptr to SyntaxNode: SyntaxNodePtr { range: [1170; 1322), kind: ENUM_DEF }', crates/ra_syntax/src/
stack backtrace:
   0: <unknown>
   1: <unknown>
   ... //  50+ lines of unknown
   note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace

Even though I have RUST_BACKTRACE=full set in my .profile and it is clearly in my env wherever I check, but the stacktrace shows unknown for some reason. @Laurențiu Nicola do you have any ideas on how to get some payload from this error?

Emil Lauridsen (Apr 07 2020 at 20:28, on Zulip):

You need to enable debug symbols in the release build profile (add debug = true to debug section of cargo.toml)

std::Veetaha (Apr 07 2020 at 20:30, on Zulip):

Ah, I wish nightly build included debug symbols, because this error happens rarely and I cannot reproduce it ...

bjorn3 (Apr 07 2020 at 20:48, on Zulip):

You don't need the debug sections for symbol names in the backtrace. You only need an unstripped binary. The backtrace is generated using .eh_frame (necessary for panic=unwind) and the symbol table. Debuginfo only gives you the file and line of the error.

std::Veetaha (Apr 07 2020 at 21:11, on Zulip):

Okay, so how do I enable the stacktrace in Cargo.toml in the better way @bjorn3?

bjorn3 (Apr 07 2020 at 21:16, on Zulip):

If you don't explicitly strip the binary, RUST_BACKTRACE should work just fine. CI does run strip binaries: so backtraces don't work for releases build on CI.

std::Veetaha (Apr 07 2020 at 22:03, on Zulip):

Hmm, you are right, maybe we shouldn't strip the binary at least for nightlies?

std::Veetaha (Apr 07 2020 at 22:04, on Zulip):

Does it give a big performance increase?

bjorn3 (Apr 07 2020 at 22:13, on Zulip):

Stripping should only affect binary size.

std::Veetaha (Apr 07 2020 at 22:26, on Zulip):

@matklad your word against?

std::Veetaha (Apr 07 2020 at 23:52, on Zulip):

As aside: I suspect this crash happens when you change the code in libraries (i.e. code from and then when the auto-import is triggered you get stale symbols from SymbolsDatabase::library_symbols() and the syntax ptr that previously referred to some struct or enum no longer resolves. I think this might be connected with Durability::HIGH that we set for library symbols, i.e. maybe this is a salsa bug, or what is more likely we messed up the inputs durability and they don't invalidate the library_symbols() query...

std::Veetaha (Apr 07 2020 at 23:53, on Zulip):


Laurențiu (Apr 08 2020 at 03:52, on Zulip):

I don't think that's supposed to work. We assume that the dependencies don't change, as far as I know.

Last update: Jul 27 2021 at 20:30UTC