ofxOsc unable to connect UDP socket crashes OF app when in login items: Mac OSX Mavericks

I have a 2013 Mac Mini (OSX 10.9.3) installed in a gallery for the next 6 months and in preparation for the long haul, I’ve set the computer to power cycle every night, restarting in the morning, have my OF app in the Mac login items, and am running Lingon with some shell scripts to keep an eye on the computer from the cloud.

The app uses the ofxOsc library to communicate bidirectionally with an iPad. Here’s the problem: When I try to auto start the OF app on login, the app crashes. Log says,

libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: unable to connect udp socket

It looks like the issue with the UDP socket happens when I create a ofxOscSender object on app load, and initialize it to a host ip that is anything outside of localhost.

If I sign into the Mac Mini with Logmein, I can launch the app no problem from the dock, but having to do that every morning for 6 months seems unnecessarily arduous. I’m using OF v0.8.0.

Has anyone had this problem before?

Here’s my bare bones implementation:
in my testApp::setup() function I call an osc setup method from my own OSC class wrapper:

void OSC::setup(string& hostname, int& recPort, int& sendPort) {
    
        receiver.setup(recPort);
    	cout << "listening for osc messages on port " << recPort << endl;
        sender.setup(hostname, sendPort);
    	cout << "waiting to send on port " << sendPort << endl;
    ... 
}

Could you post a backtrace of the uncaught exception. I wonder if the networking configuration isn’t setup by the time your application launches. If you use a static IP setup, does is the exception still thrown? If you use a symbolic hostname like gallery-ipad.local. instead of an IP, does anything change?

You should probably use a try/catch block to at least get a crack to handle the issue. Worst case scenario, you could retry sender setup after some delay, no?

Already running 10.9.3 in production? Risky :wink:

Try this version. I had the same issue which was due to the OSC IPSocket library throwing an exception. I changed it to an ofwarning message which just lets it continue on. If the device is unavailable, it just keeps the app running and the osc receiving device doesn’t get the update. It will reconnect on next transmit.

ofxOscMod.zip (81.0 KB)

Does the same issue occur with the master branch on GitHub? With oF 0.8.1 being prepared for release, it might be worth giving it a try and filing an issue / submitting a PR if it still lingers.

Thanks guys, I’m still looking into the exception but the ofxOscMod patch seems to do the trick!

Pizthewiz, I’ll try to test this with the most recent master branch and let you know what I find. I haven’t tried a symbolic hostname yet but I did try IP 0.0.0.0 with no improvement.

Updates to come…