Describe the bug
When I try to upload a ~60KB file using ZModem (apt install lrzsz && rs -evb), the client and the server hangs.
To Reproduce
Steps to reproduce the behavior:
Browse to an Ubuntu machine's ttyd server from Chrome
Upload a binary ~60KB file using rs -evb
The client will hang, and the server process will freeze at 100% CPU usage.
Expected behavior
The upload should succeed (or fail with a clear message).
Screenshots
The server log says:
ttyd 1.6.3-07ad8be (libwebsockets 2.0.3)
....
[2021/09/12 16:40:32:5820] ERR: lws_rx_sm: doing draining flow
[2021/09/12 16:40:32:5820] NOTICE: WS closed from 172.16.11.87, clients: 0
[2021/09/12 16:40:32:5820] NOTICE: killing process, pid: 19798
[2021/09/12 16:40:32:5824] NOTICE: process killed with signal 1, pid: 19798
And then the client prints:
[ttyd] websocket connection closed with code: 1006
So it's unclear who really closes the WS, because each side says it's the other one.
Environment:
OS: Linux webtest 5.4.0-1041-aws #43~18.04.1-Ubuntu SMP Sat Mar 20 15:47:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Browser: Chrome 92.0.4515.131
The server seems to have a segmentation fault in libwebsockets, but it never dies.
The server didn't respond to ignore kill -SIGTERM and also seems to ignore SIGSEGV (As I see a segmentation fault in GDB but it's still alive), and could only be killed with a SIGKILL signal.
Describe the bug When I try to upload a ~60KB file using ZModem (
apt install lrzsz && rs -evb
), the client and the server hangs.To Reproduce Steps to reproduce the behavior:
rs -evb
Expected behavior The upload should succeed (or fail with a clear message).
Screenshots The server log says:
And then the client prints:
[ttyd] websocket connection closed with code: 1006
So it's unclear who really closes the WS, because each side says it's the other one.Environment:
Linux webtest 5.4.0-1041-aws #43~18.04.1-Ubuntu SMP Sat Mar 20 15:47:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Chrome 92.0.4515.131
The server seems to have a segmentation fault in
libwebsockets
, but it never dies. The server didn't respond to ignorekill -SIGTERM
and also seems to ignore SIGSEGV (As I see a segmentation fault in GDB but it's still alive), and could only be killed with aSIGKILL
signal.