Panic when calling `:reload-all` (sometimes)

[ocharles]

Summary

Sometimes when I run :reload-all I get:

thread 'main' panicked at 'invalid HopSlotMap key used', helix-view/src/tree.rs:300:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This doesn't /always/ happen.

Reproduction Steps

So far, all I know is that I open a bunch of files and at some point call :reload-all. This causes a panic.

Helix log

No response

Platform

Linux

Terminal Emulator

Konsole

Helix Version

e6dad960cf77a3a0fae92ee216d31c9dae59b0ec

[mangas]

I have not experienced this, with a reproducible set of steps is hard to debug.

[ocharles]

I'll see if I can come up with something. I manage to reproduce this accidentally almost hourly. All I'm doing is routine editing, and then :reload-all whenever I change branches.

[gabydd]

I did experience this once(but I think I forgot to finish the bug report) I'll try and run with backtrace for the next couple days and see if I can reproduce

[gabydd]

I think I got this after I formatted the whole directory or something

[ocharles]

Here's my first backtrace:

thread 'main' panicked at 'invalid HopSlotMap key used', helix-view/src/tree.rs:300:20
stack backtrace:
   0: std::panicking::begin_panic
   1: helix_term::commands::typed::reload_all
   2: helix_term::commands::typed::command_mode::{{closure}}
   3: <helix_term::ui::prompt::Prompt as helix_term::compositor::Component>::handle_event
   4: helix_term::compositor::Compositor::handle_event
   5: helix_term::application::Application::handle_terminal_events
   6: hx::main_impl::{{closure}}
   7: tokio::runtime::park::CachedParkThread::block_on
   8: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
   9: tokio::runtime::runtime::Runtime::block_on
  10: hx::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I'm now running with RUST_BACKTRACE=full. To get this I: ran treefmt to format some of the files I've been editing, then ran :reload-all.

[ocharles]

Ok, here's a full backtrace:

RUST_BACKTRACE=full hx
thread 'main' panicked at 'invalid HopSlotMap key used', helix-view/src/tree.rs:300:20
stack backtrace:
   0:     0x55d084359204 - std::backtrace_rs::backtrace::libunwind::trace::hb729d9642bb971eb
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55d084359204 - std::backtrace_rs::backtrace::trace_unsynchronized::h373bb774579df5c7
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55d084359204 - std::sys_common::backtrace::_print_fmt::hfbd4e92d240c89bb
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x55d084359204 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8f618991fbf64972
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x55d083b0edbc - core::fmt::write::hc69b5b640d88cce8
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/fmt/mod.rs:1196:17
   5:     0x55d084352e55 - std::io::Write::write_fmt::h3403cef06a24a303
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/io/mod.rs:1654:15
   6:     0x55d08435ad9a - std::sys_common::backtrace::_print::h368f27cdedea0e52
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x55d08435ad9a - std::sys_common::backtrace::print::ha105c9cf5a64cd17
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x55d08435ad9a - std::panicking::default_hook::{{closure}}::h48ed2c3707d5e20e
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:295:22
   9:     0x55d08435aa89 - std::panicking::default_hook::h8744fc5cea5e3110
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:314:9
  10:     0x55d08435b4c4 - std::panicking::rust_panic_with_hook::hc82286af2030e925
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:702:17
  11:     0x55d0840f651b - std::panicking::begin_panic::{{closure}}::hfd5f8772f7f13664
  12:     0x55d0840f6444 - std::sys_common::backtrace::__rust_end_short_backtrace::hb9afded8c374f82f
  13:     0x55d083aa6fca - std::panicking::begin_panic::h7fbf94e8fa127260
  14:     0x55d08409a5d9 - helix_term::commands::typed::reload_all::h06c520ff14ec9762
  15:     0x55d0840a11b4 - helix_term::commands::typed::command_mode::{{closure}}::hc9b636c3c14ee2b5
  16:     0x55d0840b04cc - <helix_term::ui::prompt::Prompt as helix_term::compositor::Component>::handle_event::h24338ac740a889be
  17:     0x55d083f49fb6 - helix_term::compositor::Compositor::handle_event::hfe298d2c4a88f633
  18:     0x55d084091986 - helix_term::application::Application::handle_terminal_events::hbc4a57e0163ff0b1
  19:     0x55d0841f56e2 - hx::main_impl::{{closure}}::hc336ae293df92c1b
  20:     0x55d084203b35 - tokio::runtime::park::CachedParkThread::block_on::had0607e369ee09e5
  21:     0x55d0841bcea5 - tokio::runtime::scheduler::multi_thread::MultiThread::block_on::hce436a96ff9679d2
  22:     0x55d0841ed35e - tokio::runtime::runtime::Runtime::block_on::h9afb1b572f08ee6f
  23:     0x55d0841d0852 - hx::main::hacf51b0cfc4802ed
  24:     0x55d0841dfcf3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h7f03302a645f13d9
  25:     0x55d0841e004d - std::rt::lang_start::{{closure}}::hda2ce64a7e6378f3
  26:     0x55d08434dcde - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hf833e7144973d4be
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/ops/function.rs:280:13
  27:     0x55d08434dcde - std::panicking::try::do_call::h79761d203bfb6b46
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:492:40
  28:     0x55d08434dcde - std::panicking::try::h0561cbbe1722251d
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:456:19
  29:     0x55d08434dcde - std::panic::catch_unwind::hbca347ddd031b141
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panic.rs:137:14
  30:     0x55d08434dcde - std::rt::lang_start_internal::{{closure}}::h0492050ad281ec32
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/rt.rs:128:48
  31:     0x55d08434dcde - std::panicking::try::do_call::h3ebce69871996bb3
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:492:40
  32:     0x55d08434dcde - std::panicking::try::hbed537d20e728475
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:456:19
  33:     0x55d08434dcde - std::panic::catch_unwind::h4185e2024c6a5d05
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panic.rs:137:14
  34:     0x55d08434dcde - std::rt::lang_start_internal::h1899cfd715ca6829
                               at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/rt.rs:128:20
  35:     0x55d0841d0962 - main
  36:     0x7f1eb6ff9237 - __libc_start_call_main
  37:     0x7f1eb6ff92f5 - __libc_start_main_impl
  38:     0x55d083abbf11 - _start
                               at /build/glibc-2.34/csu/../sysdeps/x86_64/start.S:116
  39:                0x0 - <unknown>

Again, I ran treefmt in another terminal (this time after a git commit). However it doesn't always happen. Also, the treefmt command didn't actually change any files, so I'm not convinced there is necessarily correlation.

[mangas]

@ocharles can you check if you get the same when reloading a single doc?

Also thanks for the backtrace :+1: would be great to try and narrow down the reproducing steps. I'll give it a go as well locally to try and find a way to trigger it

[ocharles]

Do you mean :reload? Or to limit my hx usage to only editing a single file?

[mangas]

I meant reload but that's a good test as well. Just trying to figure out if this is something with the existing code that didn't manifest before because we were only updating one doc and one view

[the-mikedavis]

I can reproduce this. The problem is that when we close a split we don't get rid of the split's ViewId on all buffers, just the focused one.

1. touch a b: Create two files on disk
2. hx a: open a
3. <C-w>s: split so a is open in both windows in a horizontal split
4. :open b: open b in the new split
5. <C-w>q: close the split that has b focused
6. :reload-all (panics)

This panics when trying to reload a. a was focused in the second window when we created the new window. When we closed the second window, a keeps that window's ViewId in its doc.selections().

Editor::close (called by wclose (<C-w>q)) should remove the ViewId for all Documents.

[mangas]

I made reload-all a bit more defensive so we don't have a regression, let me know what you think @the-mikedavis