Bug in OSC Send/Receive : MiniAudicle hanging or crashing

[jack461]

Hi ! I just found a very annoying bug in Chuck, related to sending OSC messages. If two shreds are waiting on the same message type, stopping the first shred blocks the second, or crashes MiniAudicle. Here are two small progs that demonstrate the bug. The first on sends a sequence of OSC messages:

/*
Transmitter
*/

// Create the sender
"localhost" => string hostname;
3350 => int port;
OscOut xmit;
xmit.dest(hostname, port);

for (0 => int i; i<100; i++)
{
    xmit.start("/msg/num");
    xmit.add(i);
    xmit.send();
    <<< "                Sending", i >>>;
    1::second => now;
}

<<< "*** Emission", "end." >>>;

The second one receives OSC messages, and randomly decides to stop on one message.

/*
Receiver.
*/


// create our OSC receiver
OscIn oin;
OscMsg msg;
3350 => oin.port;
oin.addAddress("/msg/num, i");

1 => int doLoop;
int val;
Math.random2(2,8) * 10 => int stopCode;

<<< "I will stop on", stopCode >>>;

while (doLoop)
{
    oin => now;
    while (oin.recv(msg) != 0)
    {
        msg.getInt(0) => val;
        <<< "LP", me.id(), stopCode, "received", val >>>;
        if (val >= stopCode) 0 => doLoop;
    }
}

<<< "   *** LP", me.id(), "stopping on", stopCode >>>;
5::second => now;
<<< "   *** LP", me.id(), "stopped" >>>;

Now, if you run a few copies of the Receiver, and then the Transmitter, you find that as soon as one of the Receiver exits, all other Receivers hang. And sometimes MiniAudicle crashes, depending on the order in which programs are initially started.

Hope someone can find a fix...

Regards.

Jack.

[lathertonj]

Hi Jack,

I haven't worked with the OscIn or OscMsg classes before, but given that this is a pretty serious bug, they might be deprecated? Here's how I know to receive OSC messages in ChucK, and it seems to work just fine without crashing MiniAudicle. It uses OscRecv and OscEvent.

/*
Receiver.
*/


// create our OSC receiver
OscRecv oin;
3350 => oin.port;
oin.listen();
oin.event("/msg/num, i") @=> OscEvent newNum;

1 => int doLoop;
int val;
Math.random2(2,8) * 10 => int stopCode;

<<< "I will stop on", stopCode >>>;

while (doLoop)
{
    newNum => now;
    while (newNum.nextMsg() != 0)
    {
        newNum.getInt() => val;
        <<< "LP", me.id(), stopCode, "received", val >>>;
        if (val >= stopCode) 0 => doLoop;
    }
}

<<< "   *** LP", me.id(), "stopping on", stopCode >>>;
5::second => now;
<<< "   *** LP", me.id(), "stopped" >>>;

[jack461]

Hi lathertonj, many thanks for your answer ! I will try your solution tomorrow, and if I works for the tests, I will correct my programs. Do I have to change the Transmitter, or will the OscOut version work correctly with your solution (I suppose it will, since it just generates standard messages). Jack.

[lathertonj]

I don't think you have to change the transmitter! Good luck.

[spencersalazar]

Thanks all for tracking this all down. OscOut/OscIn are supposed to be the new and improved Osc classes in ChucK as they resolve a number of internal and user-facing issues with OscRecv/OscSend. Given their relative recency, there are evidently a few bugs- but I suspect this one is pretty easy to fix.

[gewang]

Years later, we have finally investigated this issue, and pushed resolutions in 1eebb38 and 3df8401.

Cause This issue was caused by two related program, especially when multiple OscIn clients are subscribed to the same OSC methods/addresses

1. synchronization bug between audio thread and server thread, leading to premature deletion of OscIn object
2. previously ADD_METHOD, REMOVE_METHOD, REMOVEALL_METHODS do not correctly handle multiple client OscIn listening for same OSC method

Remedy This led to a number of backend updates, which in the long run is a good thing...

1. new mechanism to avert race condition between audio thread & server thread between OscIn and OscInServer
2. the OscInServer message dispatch has been reworked to properly handle multiple OscIn clients, on different or same messages, on different or same ports;

Testing Have been testing variants of the original code from @jack461 (thank you) on Windows, macOS, and Linux. In addition to manually adding using OTF or miniAudicle, have been firing up different tests using CLI. For example, to run one transmitter and 8 receivers:

chuck transmitter.ck -8 receiver.ck

Thanks all for attending to this and sorry it's been years. Hopefully we can consider this issue resolved! This fix will be including in the upcoming release (1.5.1.3).

PS: related but a different: fixed Windows-specific crashing issues (#98)