Re: UDP address in use but no scsynth running..

Glad you found the issue!

> Or could it be something in VSTPlugin causing this?
I don't think so. VSTPlugin doesn't do anything related to sockets.

> I guess this problem is too specific for a generic fix
I think there is no way to fix this in VSTPlugin. Write a support e-mail
to Waves :-)

> although I would be interested to know why this happens
If you're on Windows, I have no idea.

---

If you're on macOS, then it might be related to the behavior of fork(),
which duplicates all open file descriptors of the parent process. So
what I think happens is this:

The Waves Nx plugin calls fork() + exec() to start a subprocess. That
subprocess inherits the scsynth UDP socket. When scsynth shuts down, it
closes the socket, but the same socket is still open in the subprocess,
so the listening port is not available until the subprocess closes.

There are ways to work around this in scsynth, e.g. calling
fcntl(socket, F_SETFD, FD_CLOEXEC) on the UDP socket, but I think, it
needs rather be fixed in the WavesLocalServer app.

Generally, you should close all existing file descriptors (that you
don't need) at the beginning of the child process. Often you can ignore
this and be fine if the process is shortlived and/or doesn't outlive the
parent process, otherwise you can run into troubles like this.

Christof

On 04.03.2021 10:05, [email protected] wrote:
> Ok, I got a bit further on this. The problem is actually limited to
> the Waves Nx plugin (which I use for binaural headtracked preview). It
> opens a process named WavesLocalServer, which in turn opens the same
> udp port as the server (not using it for anything as far as I can
> tell). This process keeps existing after the plugin is closed,
> blocking any future starting up of the server at that address. Doing a
> simple
>
> $ killall WavesLocalServer
>
> in terminal fixes the issue. I guess this problem is too specific for
> a generic fix, although I would be interested to know why this
> happens. Could it be that any child process opened by the server is
> automatically granted the same ports as the server itself, perhaps by
> the os? Or could it be something in VSTPlugin causing this? The
> WavesLocalServer process is also opened when using the plugin for
> example in Live, but then it doesn't open any UDP ports. It does
> always open a TCP port which I presume is used for communication with
> the headtracker application.
>
> Anyway, puzzling but at least I know a bit of what's going on now and
> how to fix without rebooting. Perhaps this could be a heads-up thread
> for anyone else using Waves Nx in SuperCollider ;-).
>
> cheers,
> Wouter
>
>> Op 2 mrt. 2021, om 22:39 heeft [email protected]
>> <mailto:[email protected]> het volgende geschreven:
>>
>> I don't see how this could be caused by the VSTPlugin extension...
>> But if you are really sure that the issue is caused by VSTPlugin,
>> please open a bug report: https://git.iem.at/pd/vstplugin/-/issues.
>> Provide a minimal code example which triggers the issue and list all
>> relevant system information (VSTPlugin version, SC version, OS version).
>>
>> Christof
>>
>> On 02.03.2021 15:37, [email protected] wrote:
>>> Yes, it seems to cause the issue. Whenever I open a VST plugin, then
>>> quit the server and try to start it again it fails. But, when
>>> changing the servers NetAddr port to 57111 (just to try a different
>>> one) the issue doesn't occur anymore, even when opening and closing
>>> VST's. Weird..
>>>
>>> I also tried the other way around; after a fresh restart, start
>>> server on port 57111, open a VST on it, free it and quit server. Now
>>> port 57111 stays open and port 57110 can be used normally (even with
>>> VST's). With nmap I can also see it (after quitting the 57111 server):
>>>
>>> $ sudo nmap -sU -p57110-57111 127.0.0.1
>>> ...
>>> 57110/udp closed       unknown
>>> 57111/udp open|filtered unknown
>>> ...
>>>
>>> This could provide a workaround to at least be able to work, but
>>> something pretty fishy seems to be going on here..
>>>
>>> cheers,
>>> Wouter
>>>
>>>> Op 2 mrt. 2021, om 14:26 heeft [email protected]
>>>> <mailto:[email protected]> het volgende geschreven:
>>>>
>>>>> I do have the VSTPlugin extension installed btw, maybe that is
>>>>> related?
>>>> I don't think so, but that's easy to test: temporarily uninstall
>>>> "VSTPlugin" and see if it resolves the problem.
>>>>
>>>> Christof
>>>>
>>>> On 02.03.2021 14:23, [email protected]
>>>> <mailto:[email protected]> wrote:
>>>>> Hi list,
>>>>>
>>>>> I'm running SC3.11.2 and I'm getting the old:
>>>>>
>>>>> *** ERROR: failed to open UDP socket: address in use.
>>>>>
>>>>> a lot. It usually happens after quitting and (re-)starting SC. Of
>>>>> course I know that this usually means a stray server is around,
>>>>> but Server.killAll doesn't do the trick and there are no scsynth
>>>>> processes around in the activity monitor. The message goes away
>>>>> only after a reboot of the machine. Any ideas what could be going
>>>>> on here? Running macOS 10.14.6 Mojave, tried signed, unsigned and
>>>>> the new big sur build (the latter doesn't give the message, but
>>>>> still says "Server 'localhost' exited with exit code 1."). I do
>>>>> have the VSTPlugin extension installed btw, maybe that is related?
>>>>>
>>>>>
>>>>> cheers & thanks,
>>>>> Wouter
>>>>> _______________________________________________
>>>>> sc-users mailing list
>>>>>
>>>>> info (subscription, etc.):
>>>>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>>>>> <http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx>
>>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
>>>>> <http://www.listarc.bham.ac.uk/marchives/sc-users/>
>>>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>>>>> <http://www.listarc.bham.ac.uk/lists/sc-users/search/>
>>>>
>>>> _______________________________________________
>>>> sc-users mailing list
>>>>
>>>> info (subscription, etc.):
>>>> http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>>>> <http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx>
>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
>>>> <http://www.listarc.bham.ac.uk/marchives/sc-users/>
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>>>> <http://www.listarc.bham.ac.uk/lists/sc-users/search/>
>>>
>