nvdaRemoteServer crashes and exits for unknown reasons

[cary-rowen]

1. I suspect it is caused by some special characters;
2. There is no stable reproduction log for the time being.
3. I can provide the following logs of the server for your analysis；
4. If you need, I can provide complete server logs in private.
5. The last line of this log is the log before the last crash and exit.

2023/03/15 15:56:14 Client 1166 has connected from 112.53.150.141
2023/03/15 15:56:14 Client 1167 has connected from 112.53.150.141
2023/03/15 15:56:17 Client 1167 has set protocol version 2.
2023/03/15 15:56:17 Client 1167 has joined channel stz1121 as a slave. This client is authorized to control other computers.
2023/03/15 15:56:37 Client 1167 has left channel stz1121
2023/03/15 15:56:37 Client 1167 has disconnected.
2023/03/15 15:57:11 Client 1168 has connected from 112.53.150.141
2023/03/15 15:57:11 Error receiving message from client 1168.
local error: tls: bad record MAC
Closing connection.
2023/03/15 15:57:11 Client 1168 has disconnected.
2023/03/15 15:57:11 Client 1169 has connected from 112.53.150.141
2023/03/15 15:57:11 Error receiving message from client 1169.
read tcp 10.0.8.2:6837->112.53.150.141:55047: read: connection reset by peer
Closing connection.
2023/03/15 15:57:11 Client 1169 has disconnected.
2023/03/15 15:57:11 Client 1170 has connected from 112.53.150.141
2023/03/15 15:57:11 Client 1170 has set protocol version 2.
2023/03/15 15:57:11 Client 1170 has joined channel stz1121 as a master. This client is authorized to control other computers.
2023/03/15 16:01:00 Client 1171 has connected from 223.104.26.142
2023/03/15 16:01:00 Client 1171 has set protocol version 2.
2023/03/15 16:01:00 Client 1171 has joined channel 123654 as a slave. This client is authorized to control other computers.
2023/03/15 16:01:03 Client 1172 has connected from 223.104.26.142
2023/03/15 16:01:03 Client 1172 has set protocol version 2.
2023/03/15 16:01:03 Client 1172 has joined channel 123654 as a slave. This client is authorized to control other computers.
2023/03/15 16:02:31 Client 1173 has connected from 42.97.244.147
2023/03/15 16:02:31 Client 1173 has set protocol version 2.
2023/03/15 16:02:31 Channel 123 has been created.
2023/03/15 16:02:31 Client 1173 has joined channel 123 as a slave. This client is authorized to control other computers.
2023/03/15 16:03:07 Error sending message to client 1159.
write tcp 10.0.8.2:6837->223.104.26.142:8635: i/o timeout
Closing connection.
2023/03/15 16:03:12 Client 1159 has left channel 123654
2023/03/15 16:03:12 Client 1159 has disconnected.
2023/03/15 16:03:12 Error sending message to client 1164.
write tcp 10.0.8.2:6837->223.104.26.142:8641: i/o timeout
Closing connection.

[tech10]

Can you give me a little context of what you're doing before the server crashes and exits? Also, if you disable the server's sending of the origin field, with the -send-origin parameter set to false, will the server still crash? If you have a way of logging anything sent to Stderr, that may be helpful as well.

[cary-rowen]

Hi,
According to your suggestion, I now set the -send-origin parameter to false and then observe again.
I'll update here if I find something new.

Can you give me a little context of what you're doing before the server crashes and exits?
I'm not so sure, another user triggered this error.
If you have a way of logging anything sent to Stderr, that may be helpful as well.
I have a list of filenames that are suspected to be causing the problem, but can't guarantee that this is the exact cause.
list(1).txt

[tech10]

I'll take a look at some of the more exotic names over my own copy of the server tomorrow, to see if it crashes on my system. I may not be able to reproduce the error, though. If you or the user that originally encountered the problem are able to reproduce it consistently and are able to provide directions on how it can be reproduced, that would be extremely helpful. If not, I probably won't be able to resolve the error, but I'm willing to keep this issue open as long as the error exists.

[cary-rowen]

I haven't found a stable way to reproduce it yet, so I'll close it. I will reopen if needed in the future

[cary-rowen]

The log recorded for the last server crash is as follows:
2023/09/02 16:46:27 Client 3137 has disconnected.
2023/09/02 16:46:45 Error sending message to client 3141.
write tcp 10.0.8.2:6837->183.11.243.242:31162: i/o timeout
Closing connection.

[tech10]

I've encountered this error myself, but it's never crashed the server. Is there anything you know of that's precipitated the crash, or is it a simple loss of connection?

[cary-rowen]

I haven't found the exact reason yet, the server program crashed and exited, and I had to rerun it.

[tech10]

What operating system are you running?

Also, if you try and compile the program yourself with Go, will the issue still occur? I've not updated the binary releases to Go version 1.21 yet, perhaps the latest version fixed something, though I've not seen anything in the history change logs that might indicate this could be a problem on older releases of Go.

[cary-rowen]

Hi @tech10
The following is my server version information:
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy

BTW, I haven't tried compiling the latest version myself yet, it would be great if you could release a new version.

Thanks

[tech10]

I've started the release process, it should be uploaded in about eight minutes. It should be using Go 1.21.0 for the release.

[cary-rowen]

I have upgraded to v1.1.11 to take a closer look and I will update here if there are new findings.