1

Recently I wrote a Discord-Bot in C++ with the sleepy-discord bot library. Now, the problem here is that when I run the bot it shows me the following errors:

[2021-05-29 18:30:29] [info] Error getting remote endpoint: asio.system:9 (Bad file descriptor)
[2021-05-29 18:30:29] [error] handle_connect error: Timer Expired
[2021-05-29 18:30:29] [info] asio async_shutdown error: asio.ssl:336462100 (uninitialized)

Now, I searched far and wide what this could be triggered by but the answers always say like a socket wasn't opened and so on. The thing is, it works on a lot of systems, but yesterday I was renting a VM (same system as my computer), and this seems to be the only one giving me that issue.

What could be the reason for this?

Edit: I was instructed to show a reproducible example, but I am not sure how I would write a minimal example that's why I link the bot in question: https://github.com/ElandaOfficial/jucedoc

Update:

I tinkered a bit around in the library I am using and was able to increase the Websocketpp log level, thankfully I got one more line of information out of it:

[2021-05-29 23:49:08] [fail] WebSocket Connection Unknown - "" /?v=8 0 websocketpp.transport:9 Timer Expired
Elanda
  • 13
  • 3

1 Answers1

1

The error triggers when you so s.remote_endpoint on a socket that is not connected/no longer connected.

It would happen e.g. when you try to print the endpoint with the socket after an IO error. The usual way to work around that is to store a copy of the remote endpoint as soon as a connection is established, so you don't have to retrieve it when it's too late.

On the question why it's happening on the particular VM, you have to shift focus to the root cause. It might be that accept is failing (possibly due to limits like number of filedescriptors, available memory, etc.)

sehe
  • 374,641
  • 47
  • 450
  • 633
  • hmm... I have 4gb of ram, so that can't be the cause. I also set the file descriptors to 4096, so that is neither. – Elanda May 29 '21 at 22:35
  • That's why I suggested looking into what the root cause is. It's unlikely you will "just realize it" by sheer will. Maybe you can add tracing/error handling, statistics – sehe May 30 '21 at 11:43
  • I see you added the "Timer expired" info. In that case it is very likely that the expiration closes the socket, and some other part of the code tries to execute `remote_endpoint` after that. (In fact, you can almost guess that in that log line you posted they're maybe handling a similar problem resulting in "Connection Unknown" being displayed?) – sehe May 30 '21 at 11:45
  • So that means it timeouts before establishing a successful connection? – Elanda May 30 '21 at 14:56
  • That's one option. It's also possible that the timer expires just after the socket has been closed. Or that the expiration itself is causing the socket to be closed and you have another unguarded invocation of `remore_endpoint` after that. In all cases this is likely an async "race" as is pretty common in Asio (see eg https://stackoverflow.com/a/43169596/85371) – sehe May 30 '21 at 17:07