tmux now crashes after tmux update using `tmux-continuum` and `@continuum-restore` option

[eduncan911]

I recently updated my tmux to latest 2.2 released n April 2016 and now it crashes when I have tmux-continuum enabled in the config file. Commenting out tmux-continuum allows it to restart (but without my sessions!!).

$ tmux
lost server

Tmux version:

$ brew info tmux
tmux: stable 2.2 (bottled), HEAD
Terminal multiplexer
https://tmux.github.io/
/usr/local/Cellar/tmux/2.2 (9 files, 639.7K) *
  Poured from bottle on 2016-06-13 at 09:28:28
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/tmux.rb
==> Dependencies
Build: pkg-config ✔
Required: libevent ✔

I am on the latest revision:

$ cd ~/.tmux/plugins/tmux-continuum/
$ git log
commit 499b6a7e4e8d5a8dbfd15ebedacefa1c0a66ff2f
Merge: d21e477 438e50d
Author: Bruno Sutic <removed>
Date:   Sat Jan 23 16:57:14 2016 +0100

    Merge pull request #17 from jarosser06/rm_hardcoded_home

    Replaced hardcoded home directory in Systemd ExecStop with HOME variable

FYI: My Mabcook Pro's CPU also gets up to 35% CPU usage with OSX trying to report the crash in the background: /System/Library/CoreServices/ReportCrash. Until I exit the shell that attempted to run tmux, it continually heats up the CPU.

Per issue guidelines:

• a file symlinked to ~/.tmux/resurrect/last.

This is what my last is symlinked to when I manually saved it: tmux_resurrect_2016-06-11T23:21:24.txt

• your .tmux.conf

https://github.com/eduncan911/dotfiles/blob/master/.tmux.conf

• if you're getting an error paste it to a gist and link it in the issue

This is all I get since the Homebrew version doesn't have debug builds.

$ tmux
lost server

[eduncan911]

It seems to be an issue with the @continuum-restore option. If I comment it out, I can get tmux to load.

set -g @continuum-save-interval '15'
#set -g @continuum-restore 'on'
run-shell ~/.tmux/plugins/tmux-continuum/continuum.tmux

Furthermore, I can even restore my last sessions with <prefix>-CTRL-r and everything is fine.

Was mentioning in another issue #19 that it has been working up to this point.

[tfiala]

GitHub doesn't seem to let me attach the crashlog, but here's the relevant bits I'm getting with @continuum-boot 'on' and @continuum-restore 'on':

Process:               tmux [10598]
Path:                  /usr/local/Cellar/tmux/2.2/bin/tmux
Identifier:            tmux
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           tmux [10598]
User ID:               501

Date/Time:             2016-09-23 20:23:17.915 -0700
OS Version:            Mac OS X 10.12.1 (16B2327e)
Report Version:        12
Anonymous UUID:        FC1D6F86-CB82-1490-1B92-4DE59932777D


Time Awake Since Boot: 790 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000590
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0x590:
--> 
    __TEXT                 000000010ba20000-000000010ba6f000 [  316K] r-x/rwx SM=COW  /usr/local/Cellar/tmux/2.2/bin/tmux

Application Specific Information:
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   tmux                            0x000000010ba4f83f status_prompt_clear + 9
1   tmux                            0x000000010ba4f672 status_message_set + 156
2   tmux                            0x000000010ba277d6 cmd_display_message_exec + 287
3   tmux                            0x000000010ba2d234 cmdq_continue + 274
4   tmux                            0x000000010ba4ac36 server_client_dispatch_command + 338
5   tmux                            0x000000010ba49046 server_client_dispatch + 310
6   tmux                            0x000000010ba456f1 proc_event_cb + 114
7   libevent-2.0.5.dylib            0x000000010ba930cd event_base_loop + 1650
8   tmux                            0x000000010ba455b3 proc_loop + 40
9   tmux                            0x000000010ba4bf55 server_start + 386
10  tmux                            0x000000010ba245cd client_connect + 622
11  tmux                            0x000000010ba24819 client_main + 265
12  tmux                            0x000000010ba520d9 main + 1660
13  libdyld.dylib                   0x00007fffcdac2255 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000064  rbx: 0x0000000000000000  rcx: 0x0000000000000019  rdx: 0x00007f9162f06120
  rdi: 0x0000000000000000  rsi: 0x00007f9162d02854  rbp: 0x00007fff541de0d0  rsp: 0x00007fff541de0c0
   r8: 0x0000000000000000   r9: 0x00000000000007a0  r10: 0x00007f9162f00000  r11: 0x0000000000002800
  r12: 0x0000000000000000  r13: 0xca9f7345fc4a0029  r14: 0x0000000000000064  r15: 0x000000010ba6b85a
  rip: 0x000000010ba4f83f  rfl: 0x0000000000010246  cr2: 0x0000000000000590

Logical CPU:     4
Error Code:      0x00000004
Trap Number:     14

If I had to take a guess, the forked process may be trying to do something with exception ports or file handles (possibly with posix_spawn file actions) that are invalid, and its causing the post-fork, pre-exec file handling to blow up.

[Hultner]

I'm having the same problem, didn't always have it but started recently. Often times I can't even restore the session manually which have made me considering moving back to a tmuxinator based workflow even though I prefer tmux-continuum.

[eduncan911]

Since I filed this issue (almost 1 year ago), I've just left @continuum-restore commented out and have gotten into the habit of always "Restoring Manually" after I first launch tmux - if I want everything restored.

And actually, it isn't a bad workflow to have the option to not restore everything when I launch tmux. Restoring my 15+ sessions and 40+ windows and panes does take about 10s on a 2016 Macbook Pro 15" Retina with a very fast M.2 drive. But there are times where I just want simple tmux window funsies before getting back into my developer groove after a reboot.

I've even disabled the save interval, which I never really got working on macos either. I did that so not to accidentally overwrite my last set of sessions. E.g. I just started tmux and haven't restored yet.

I'm actually back to just saving and restoring everything manually.

Therefore, I won't actually use this feature once (or if) it is fixed.

You can always view my latest .tmux.conf on my dotfiles:

https://github.com/eduncan911/dotfiles/blob/master/.tmux.conf

I usually keep it compatible between Linux and macOS. There is currently an error with Linux using my config though for the reattach-to-user-namespace fix for macOS. On my linux machines, I just comment out those lines.

[elulcao]

2021 and still reproducible Im using tux 2.9 and crashing if set -g @continuum-restore 'on' defined.

[ismet55555]

2022 and still reproducible I'm using tmux 3.2a and crashing if set -g @continuum-restore 'on' defined.

Additionally, when I have that option off and I try to restore with Prefix Ctrl-r, it crashes/exits just the same.

Interesting, this just happened today, everything was fine before that for a while. I'm assuming that it has something to do with the saved restore-points that may be corrupted somehow.

So I tried something, that seems to work. It basically replaces the last restore point with the second to last restore point.

1. cd into ~/.tmux/resurrect
2. Move the second the last saved restore point out of this directory
   • mv tmux_resurrect_20220415T160716.txt ..
3. Remove all .txt files in ~/.tmux/resurrect
   • rm tmux*.txt
4. Remove the symlink of the last session
   • rm last
5. Move that session back into ~/.tmux/resurrect
   • mv ../tmux_resurrect_20220415T160716.txt .
6. Create the symlink
   • ln -s tmux_resurrect_20220415T160716.txt last
7. Start tmux and restore

[ismet55555]

2022 and still reproducible I'm using tmux 3.2a and crashing if set -g @continuum-restore 'on' defined.

This seems to be an issue with the last restore .txt file. It has somehow become corrupt.

To get around it, you will have to delete the last symlink inside the ~/.tmux/resurrect directory. Then symlink another, previous restore .txt file.

cd `~/.tmux/resurrect
rm last
rm tmux_resurrect_<LATEST>.txt
ln -s tmux_resurrect_<PREVIOUS>.txt last

[victor141516]

2022 and still reproducible I'm using tmux 3.2a and crashing if set -g @continuum-restore 'on' defined.

This seems to be an issue with the last restore .txt file. It has somehow become corrupt.

To get around it, you will have to delete the last symlink inside the ~/.tmux/resurrect directory. Then symlink another, previous restore .txt file.

cd `~/.tmux/resurrect
rm last
rm tmux_resurrect_<LATEST>.txt
ln -s tmux_resurrect_<PREVIOUS>.txt last

This happened some times to me, but today it happened that the directory ~/.tmux/resurrect was deleted somehow and continuum was not expecting that.

Solution: recreate the directory

mkdir -p ~/.tmux/resurrect

[elulcao]

2022 and still reproducible I'm using tmux 3.2a and crashing if set -g @continuum-restore 'on' defined.

This seems to be an issue with the last restore .txt file. It has somehow become corrupt.

To get around it, you will have to delete the last symlink inside the ~/.tmux/resurrect directory. Then symlink another, previous restore .txt file.

cd `~/.tmux/resurrect

rm last

rm tmux_resurrect_<LATEST>.txt

ln -s tmux_resurrect_<PREVIOUS>.txt last

This happened some times to me, but today it happened that the directory ~/.tmux/resurrect was deleted somehow and continuum was not expecting that.

Solution: recreate the directory

mkdir -p ~/.tmux/resurrect

2024 and still reproducible. The fun fact is that plugin trigger the error message just after initial launch after fresh installation. I restarted tmux server, terminal and OS without any luck. The solution was to recreate the directory with mkdir command.