wezterm icon indicating copy to clipboard operation
wezterm copied to clipboard

mux server crash w/ multiple clients with different window sizes

Open jsgf opened this issue 3 years ago • 2 comments

What Operating System(s) are you seeing this problem on?

Linux Wayland

WezTerm version

wezterm 20220606-221602-a323935b

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

I have a long-running mux server running, which I connect to from a couple of client machines. This morning I found it not working, and saw this in its log output:

09:36:15.863  ERROR  wezterm_mux_server::ossl     > process: encoding PDU to client

Caused by:
    0: writing pdu data buffer
    1: Connection reset by peer (os error 104)
09:36:23.005  ERROR  env_bootstrap                > panic at term/src/screen.rs:414:9 - !?
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: __libc_start_main
  18: <unknown>

thread 'main' panicked at 'phys_row called with negative row -37', term/src/screen.rs:414:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I suspect this is when I connected my second machine to the server. This looks to me like a bounds error from having mismatched window sizes on the two machines.

To Reproduce

Repro as above - I haven't tried to systematically reproduce it.

Configuration

Just:

return {
     tls_servers = { ... }
}

where all the parameters are not really relevant.

Expected Behavior

I'm not really sure what the most correct behaviour should be for a multi-client mux use case. Things like window sizes are necessarily going to be different. I guess the server's logical window size should be whatever the last client sent, and the other clients see a viewport onto that new window size. Definitely shouldn't crash.

Logs

09:36:15.863 ERROR wezterm_mux_server::ossl > process: encoding PDU to client

Caused by: 0: writing pdu data buffer 1: Connection reset by peer (os error 104) 09:36:23.005 ERROR env_bootstrap > panic at term/src/screen.rs:414:9 - !? 0: 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: __libc_start_main 18:

thread 'main' panicked at 'phys_row called with negative row -37', term/src/screen.rs:414:9 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Anything else?

No response

jsgf avatar Jun 17 '22 17:06 jsgf

The panic portion of this is fixed now in main, but I haven't put any significant thinking into reconciling the different screen sizes yet.

wez avatar Jul 26 '22 16:07 wez

We now make a small effort to resize to the max height + width of the local and remote. It's imperfect, but a bit better than the nothing we were doing before

wez avatar Aug 05 '22 15:08 wez

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

github-actions[bot] avatar May 03 '23 03:05 github-actions[bot]