ofxOsc strange behaviour/bug using the examples - please help

Hi folks!

I encounter a very strange situation here: After starting my computer, I can compile and run the OSC send/receive examples from current master successfully - they talk to each other, messages get transmitted, everything is as it should be.
If I start the applications again - nothing; it seems there’s no connection, the messages don’t get transmitted, it does not work.
This seems independent of how I close the apps on the first run (ESC or window close button). A make clean/make cycle for both example apps does not help. I can only get it to work again after a reboot it seems.
This is on ubuntu64.

I have no idea why this happens, and have been tearing my hair out! :’(
any pointers? what can I do to further diagnose the problem? Any known causes/problems? Can anyone reproduce this?

please help :frowning:

OK, further investigation shows that this works without problems on 32bit ubuntu. will investigate more, maybe the 64bit projects have gone bonkers? or possibly a problem with the 64bit Osc library?

OK, so it seems to be a problem with 64bit. the code I wrote today works flawlessly on my 32bit machine, but there’s no communication on my 64bit machine.
any pointers? are there known problems with 64bit ofxosc?

Which version of OSCpack is used in oF (I couldn’t determine that)?
Since the release of the last stable one (1.0.2 ind aug2010), there have been some fixes related to 64bit - maybe those fix this bug?
http://code.google.com/p/oscpack/source/detail?r=54
http://code.google.com/p/oscpack/source/detail?r=57

I’m not sure which version of oscpack we’re using. My guess is that one of the calls to close() in UdpSocket is failing somehow and the socket itself isn’t being closed. None of those changes seem to have anything to do with that low-level functionality, so I’m not sure what might have changed. I compiled+ran their newest 64 bit code on OSX and it works fine. As soon as I get home I’ll try it on my linux machine and report back. Thanks,

After recompiling the oscpack for linux 64 (had to add some #include <stdlib.h> declarations here and there to get it to work) I can’t get the same behavior as you. Try this one and see: http://thefactoryfactory.com/liboscpack.a

If it doesn’t work, you might try running the samples from oscpack and see if the same problem exists for you.

hm, after drop-in replacing the library, cleaning and recompiling everything, I get (on ubuntu 11.04 64bit btw)

  
obj/x86_64Release/addons/ofxOsc/src/ofxOscSender.o: In function `ofxOscSender::appendMessage(ofxOscMessage&, osc::OutboundPacketStream&)':  
make[1]: Leaving directory `/media/windata/Visuals/Coding/openFrameworks/apps/myapps/oscSenderExample'  
ofxOscSender.cpp:(.text+0xf2): undefined reference to `osc::OutboundPacketStream::operator<<(int)'  
collect2: ld returned 1 exit status  
make[1]: *** [bin/oscSenderExample] Error 1  
make: *** [all] Error 2  
  
**** Build Finished ****  

Maybe I miss something obvious, I’m tired. I’ll go to bed now, take a fresh look tomorrow.
Thanks for your efforts so far!

I’m wondering if this is to do with the header and the .a being out of sync, b/c the operator overload for OscPacketListener looks like this:

  
#ifndef __x86_64__  
  
    OutboundPacketStream& operator<<( int rhs )  
  
            { *this << (int32)rhs; return *this; }  
  
#endif  
  
  

Try putting the new headers in there and see if that changes anything and a busy non-OF && not in front of my computer day & I’m trying to unsnarl my 007 linux install before I go, as soon as I do I can dig into this more and see what’s going on.

hm, so this ifndef was changed in the r57 i linked above, but it’s already this was in the 007 ofxosc. So i presume the 007 oxfOsc was made with at least r57. OTOH, the beginning of OscTypes.h is subtly different between current oscpack and 007 ofxosc, so I guess there were some tweaks.

from what I can see browsing code (I can only get to my 64bit machine in the evening), this operator<<(int rhs) does not get defined for 64bit systems (as per the snippet you posted above). I don’t get why they make this exclusion, though.
There’s only operator<<(int32 rhs) from the line above that available, that’s why the undefined reference error occurs - int32 is a typedef for signed int on 64bit.
I’ll try with the current oscpack headers and see what happens in the evening.

I can confirm that the new oscpacklib works fine with new headers, though I’m not sure that this will solve your problem. The define may not have been triggered when the lib was compiled, if it was compiled on a 32bit machine, hence the conflict? Not sure.

hm, strange, I still get the error with the undefined reference.
you mean the “new oscpacklib” you compiled and linked to above, right? and the new headers which I get by checking out the latest oscpack source from the google code page, right?
Did you compile it on a 32bit machine, or how do you mean the above question?
I (sanity)checked on my side, the symbol __x86_64__ is defined.
I don’t get the whole thing at all…

Well, I think I’ll start over with this, and see if I can debug the initial error in more detail, so I don’t have to blindly use new libraries - maybe the error is elsewhere anyway (with me probably).

So I recreated all my Eclipse projects. No dice, still not working. :frowning:

can anyone reproduce my problems here at all, using the stock 007 ofxOsc and 64bit Ubuntu?
Frankly, I’m at a loss how to debug that…

some more insight: this only seems to affect the receiving side. If I switch the port to another one and back again (by calling oscReceiver.setup(int port)) during runtime, communication works flawlessly from that point on…

ah, yeah, I also created an issue for this: https://github.com/openframeworks/openFrameworks/issues/701

so, regarding the problem with operator<<, it seems we’re not the only ones having problems on 64bit:
http://code.google.com/p/oscpack/issues/detail?id=4#c0

Have you tried the fix they suggest there and are still have problems with it?

not yet, haven’t had the opportunity, just wanted to point it out. I will try, though.