nushell / nushell/nushell

explore panics in debug mode

Open
#13,547 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

category:bug panic
Dominant language
Rust
Stars
40.5k
Forks
2.3k
Avg merge
1d 19h
Merged PRs (30d)
85

Description

Describe the bug

explore panics when scrolled past the end

How to reproduce
  1. run $env | explore
  2. Keep using PageDown till it stops scrolling
  3. Pres the down arrow
Expected behavior

Do nothing (already viewing the end of table)

Screenshots
 × Main thread panicked.
  ├─▶ at crates/nu-explore/src/views/record/mod.rs:697:5
  ╰─▶ 77 76
  help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace.

This is on

fn get_percentage(value: usize, max: usize) -> usize {
    debug_assert!(value <= max, "{value:?} {max:?}");
Configuration
key value
version 0.96.2
major 0
minor 96
patch 2
branch
commit_hash
build_os linux-x86_64
build_target x86_64-unknown-linux-gnu
rust_version rustc 1.78.0 (9b00956e5 2024-04-29)
rust_channel 1.78.0-x86_64-unknown-linux-gnu
cargo_version cargo 1.78.0 (54d8815d0 2024-03-26)
build_time 2024-08-03 20:14:38 -07:00
build_rust_channel debug
allocator mimalloc
features default, sqlite, system-clipboard, trash
installed_plugins
Additional context

The problem seems to be WindowCursor manages both "view" and a "window" that sometimes seems to be assumed to fit within the view. But sometimes it isn't clamped on update and this seems to trigger the debug_assert.

I was looking at fixing, but realized the current design is a bit unhandy:

  • WindowCursor has view and window fields
    • But the view field really defines the view size and window position
    • While the window field defines the window size and cursor position within the window
    • So if you want to move the window, you update the view field!
  • We need to maintain the invariant that the window always fits within the view (so that the cursor can't move past data)
    • With the current design it's lossy - you can keep clamping the window due to operations on WindowCursor, but you lose the original size and so can't reliably "unclamp" it on reverse operations
    • In practice it kind of works because the drawing code happens to reset window sizes - but it still feels unnatural it's needed, could lead to issues in the future and might already be a problem (if the reset happens too early/too late); not sure
    • Alternatively, we could "merge" Cursor into WindowCursor so that we can preserve the window size information (while reporting the clamped value via the public API). With Cursor being a separate thing, many methods don't have enough information to do that.

Any thoughts about getting rid of Cursor as a separate entity so that we can preserve the original window size?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the debug-mode panic with $env | explore, paging past the end and pressing the down arrow. Inspect crates/nu-explore/src/views/record/mod.rs around get_percentage and the WindowCursor/Cursor behavior described in the report. Done means reaching the end of the table and pressing down no longer triggers the debug assertion.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.