[tmux-resurrect] Cache broken on restoring (Error ble.sh: The keymap 'vi_imap' is empty.)

ble version: 0.4.0-devel3+750ca38
Bash version: 5.0.17(1)-release (x86_64-pc-linux-gnu)

I am getting ble.sh: The keymap 'vi_imap' is empty. after restoring my tmux session, and ble.sh is not loading.

I am also unable to see any key press in the terminal, unless I do tput reset

~~I have went back to 0506df28baa6a and not getting this error.~~

I have went back to 0506df2 and not getting this error.

Thank you for the report! Can you identify the commit where the problem starts by using binary search (or manual git bisect)?

Weird!! After, rebuilding from latest master, it went away.

Hmm, seems like, it only happens when tmux session is restored even for 0506df2

I am using a plugin called tmux-resurrect with tpm.

Weird!! After, rebuilding from latest master, it went away.

Ah, OK. I think it was because the keymap cache has been updated by switching the commit.

Actually, I recently experienced the same phenomena in my local testing once. I found that this is caused by an empty keymap cache file $_ble_base_cache/keymap.vi, but I couldn't find the reason why the file became empty and couldn't reproduce the same phenomena anymore. Now it seems you can reproduce the problem, I'd like to further collect the information.

Hmm, seems like, it only happens when tmux session is restored even for 0506df2

I am using a plugin called tmux-resurrect with tpm.

I'm actually not sure what tmux-resurrect does, but does it mean if you just reattach the tmux session without using tmux-resurrect, the problem doesn't reproduce?

Persists tmux environment across system restarts.

tmux-resurrect allows to save a session, manually (prefix + ctr +s) or automatically at some interval. So, even after you kill that session, you can still get that session back (like panes, windows and so on). It makes it also possible to get the session back after reboot of machine.

Thank you for the explanation. I'm looking at the manual of tmux-resurrect. Now I'm wondering if it tries to restore the Bash session as well (including the current directory, aliases, user-defined key-bindings, etc.) not only the tmux window layout? It says it restores the state of vi, emacs, etc. but doesn't mention bash which I think the most essential which is weird.

Maybe it is different from the problem that I experienced before. I think I can try to set up tmux-resurrect tomorrow in my machine to see if the same problem reproduces. For now, could you see whether the file $_ble_base_cache/keymap.vi is empty when the problem is present?

$ ls -l "$_ble_base_cache/keymap.vi"

Before resurrection

md5sum:
0b5037c79032706a9ae7858a3a920c7b ~/.cache/blesh/0.4/keymap.vi

not empty

After resurrection:

The error happens and nothing typed can be seen in the window.
After
tput reset
the typing appears.

And, yes the ~/.cache/blesh/0.4/keymap.vi is empty. :)

Thank you! OK... the cache file becomes indeed empty by tmux-resurrect. It's really puzzling that the cache file is affected by the resurrection... I'll try to find what's happening.

For the time being, If you want to soon use ble.sh, you can just delete the file $_ble_base_cache/keymap.vi every time when the problem started to happen.

Hi, I have set up tmux-resurrect using tpm, saved a session with prefixC-s, and restored prefixC-r, but it just works without problems. I have questions:

Q1: Could you describe the precise procedure to reproduce the problem? I have tried prefix C-s (save session) prefix C-r (restore session) prefix c (create new window), but there seems to be no problems.
Q2: Does the problem occur without ~/.inputrc?
```
$ cd
$ mv .inputrc .inputrc.backup20210515
$ tmux
```
Try to reproduce the problem, e.g. prefix C-sprefix C-rprefix c, etc.

After testing you can restore the .inputrc file.
```
$ cd
$ mv .inputrc.backup20210515 .inputrc
```
Q3: Does the problem occur without any configuration in .bashrc other than ble.sh? Similarly to the .inputrc case, you can rename your .bashrc to the temporary one, create a new ~/.bashrc with a single line source /path/to/ble.sh --norc, start tmux session, save and restore the state using tmux-resurrect. After the testing, you can restore your original .bashrc.

I actually cannot reproduce it anymore. Not sure why.

But, yesterday the steps mentioned at Q1 would reproduce it. I will try again tomorrow.

Q2: Does the problem occur without ~/.inputrc?

Removing inputrc also is not reproducing it.

Hmm, heisenbug... Have you changed your shell configuration or system configuration or updated some softwares since you last reproduced the problem?

I'm looking at code and thinking of possible causes.

One possibility might be caused by wrong timestamps. Maybe, when you have tested it yesterday, the timestamps of some files have been set to the future time (but before now). Do you use NFS or SSHFS, or some other types of network drives? Or have you changed your system time recently (before you found the problem)?
Another possibility: I'm not sure if it really causes problem, but do you have several different versions of ble.sh installed on different directories?

Hi, did the problem appeared again in your environment? It seems that the problem cannot be reproduced on my side. Nevertheless, I added a workaround for the phenomena of the vi_imap cache becoming empty in commit 560160b. Now ble.sh checks that the cache is non-empty before reading the cache file. This fix doesn't solve the root cause but is just a workaround for the resultant phenomena of the empty vi_imap cache, so possibly some other problems are still present. If you have noticed something additional, please let me know. Thank you!

I ran into this again on today's master (690b315), with the emacs keymap instead of vi_imap: ble.sh: The keymap 'emacs' is empty. in several tabs after kitty restored a 32-tab session, right after ble-update and a reboot.

It is a race between concurrent shells, which is why it never reproduced in a single tmux window here. The caches under $_ble_base_cache are written in place with >|, so when many shells start with a stale cache at the same time, one shell truncates and rewrites keymap.emacs while the others already pass the -s/-nt checks and source the half-written file. The -s workaround from 560160b only covers the zero-byte instant; the file is non-empty and broken for most of the write. A half-written decode.bind.* shows up as a bash syntax error instead.

Reproduction: 32 bash -i in ptys started simultaneously against an empty XDG_CACHE_HOME. On master, 11, 0, 23 and 13 of 32 shells failed to attach across four runs. With the caches written to <file>.$$.part and renamed into place, 0 of 32 in three runs.

Patch: #727

Navigation Menu

Repository navigation

[tmux-resurrect] Cache broken on restoring (Error `ble.sh: The keymap 'vi_imap' is empty.`) #109

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[tmux-resurrect] Cache broken on restoring (Error ble.sh: The keymap 'vi_imap' is empty.) #109

Description

Activity

RakibFiha commented on May 14, 2021

akinomyoga commented on May 14, 2021

RakibFiha commented on May 14, 2021

RakibFiha commented on May 14, 2021

akinomyoga commented on May 14, 2021

RakibFiha commented on May 14, 2021

akinomyoga commented on May 14, 2021

akinomyoga commented on May 14, 2021

RakibFiha commented on May 14, 2021

akinomyoga commented on May 14, 2021

akinomyoga commented on May 15, 2021

RakibFiha commented on May 15, 2021

akinomyoga commented on May 15, 2021

akinomyoga commented on May 15, 2021

akinomyoga commented on May 20, 2021

vnz commented on Sep 7, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

[tmux-resurrect] Cache broken on restoring (Error `ble.sh: The keymap 'vi_imap' is empty.`) #109