I believe this happened as I was trying to enter a folder, either during or shortly after a refresh.
I've had this ncdu running for several days with multiple refreshes and deleted files both within ncdu as well as in a separate rclone delete process while cleaning things up.
I can't reproduce this issue as it just happened randomly after days of not having any issues while doing this.
Maybe this information is enough to find the issue, if it's not, feel free to just close this.
Run the command 'rclone version' and share the full output of the command.
as I said, I can't reproduce it, neither with the old nor current version, so if it's already fixed or can't be determined from this then it is how it is.
That was enough description for me to reproduce this
I made a test directory and within that made another directory with 1000 files
mkdir ncdu-test
cd ncdu-test
mkdir 1000files
cd 1000files
for in in $(seq -w 999); do echo $i > $i ; done
cd ..
I then ran rclone ncdu . went into the 1000files directory, scrolled down to the end and went back to the root.
Now in another terminal window I deleted those 1000 files, but not the directory they were in, pressed R in ncdu and went back into the 1000file directory.
BOOM same panic as above!
panic: runtime error: slice bounds out of range [690:0]
goroutine 1 [running]:
github.com/rclone/rclone/cmd/ncdu.(*UI).Draw(0xc0005ff680)
/home/ncw/go/src/github.com/rclone/rclone/cmd/ncdu/ncdu.go:389 +0x19a8
github.com/rclone/rclone/cmd/ncdu.(*UI).Run(0xc0005ff680)
/home/ncw/go/src/github.com/rclone/rclone/cmd/ncdu/ncdu.go:1066 +0x1055
github.com/rclone/rclone/cmd/ncdu.glob..func1.1()
/home/ncw/go/src/github.com/rclone/rclone/cmd/ncdu/ncdu.go:86 +0x25
github.com/rclone/rclone/cmd.Run(0x0, 0x0, 0x1?, 0xc000d2bcb8)
/home/ncw/go/src/github.com/rclone/rclone/cmd/cmd.go:258 +0x130
This is caused by the remembered position for each directory being incorrect after a directory refresh.
I guess I could clear them all on Refresh which would be very easy but perhaps annoying as the refresh proceeds in the background. I guess the user could do stuff while the refresh is proceeding and make invalid markers again.
Perhaps the best plan is to bounds check them when they are re-used.
Thanks, just tested with your reproduction steps, while it does reliably crash 1.64.2, it does indeed no longer panic for me either when building from the fix-ncdu-crash branch with make rclone.
Thanks for testing I've merged this to master now which means it will be in the latest beta in 15-30 minutes and released in v1.65 - if I end up making a v1.64.3 I'll put it in that too.