SC_UdpInPort: received error

After evaluating CmdPeriod.hardRun (SC 3.13.0-dev, Windows 10), under the internal server… on a local machine:

SC_UdpInPort: received error - An existing connection was forcibly closed by the remote host

Is there reason for concern?

It’s been a while since I’ve launched SC in Windows, but my recollection is that this message is printed more often in Windows than in other OSes. One odd thing here is that the internal server doesn’t use a network port at all, so I suspect the error is unrelated to the server.

It should be only a temporary situation (worst case, relaunch SC).


It’s started to occur lately with no changes in setup… it’s truly rather strange.

Any further insight from anyone would be appreciated… even shot in the dark.

I’m afraid I may have to boldly pull out the big guns here…

@Josh @MarcinP …any ideas?

I just received this after launching SC on a fresh boot, pressing Ctrl+B (booting the local server…) and then promptly running s.quit after a few moments:

server ‘localhost’ disconnected shared memory interface
‘/quit’ message sent to server ‘localhost’.
-> localhost
SC_UdpInPort: received error - No connection could be made because the target machine actively refused itServer ‘localhost’ exited with exit code 0.

The missing newline between ‘it’ & ‘Server’ is exactly as it was displayed at the time of error.

TL;DR – Don’t worry about it.

Full answer:

I searched the source code for the place where these messages are printed. There are two places: one in the language, one in the server.


        printf("SC_UdpInPort: received error - %s\n", error.message().c_str());


            printf("SC_UdpInPort: received error - %s", error.message().c_str());

Note that the language one includes a newline \n, but the server one does not. And, the transcript you posted is missing the newline (“refused itServer”).

Now, it’s a bit silly that we have to search the source code and use the presence or absence of a newline to determine which process is printing the error message, but the answer is pretty conclusive: it’s the server.

About this, two points.

First, the server is quitting at the time. So, anything related to UDP communication for this server process will be irrelevant within a few milliseconds, because that process will be gone = Don’t worry about it.

Second, the language-side comport includes, in SC_UdpInPort::handleReceivedUDP():

    if (error == boost::asio::error::connection_refused) {
        // avoid windows error message

The comment tells me that we get this error spuriously in Windows, but not in other OSes, and that this was annoying enough to suppress only this error.

But this if was never ported into the server comport. (If it were there, it would be at ./server/scsynth/SC_Comport.cpp line 209, but it’s not.)

… which leads to the same “Don’t worry about it”: if one process suppresses the error, then it can’t be important.

I’d suggest filing a bug report, for two things:

  1. Distinguish SC_UdpInPort errors: language should say "sclang SC_UdpInPort: received error - %s\n" and server, "scsynth SC_UdpInPort: received error - %s\n". (And, at the same time, fix the missing newline.)

  2. Add the if (error == boost::asio::error::connection_refused) block into the server source.


I think this is a pretty quick pull request – I’ll just do it now.


Many, many thanks chief… and thanks letting me know I wasn’t getting hacked…