radarsat1 / liblo Goto Github PK

running a test-build on mingw64 (cross-compiling from Debian/amd64), i found that the liblo.def misses a declaration of lo_server_max_msg_size()

I tried to send this to the mailinglist, but think it bounced..

Is there any chance of a recipe.sh for buildozer ?

It should be really similar to build/android-build.sh I just don't grok the android build stuff enough to port it - I guess the main difference is just using the toolchain etc that buildozer passes in via env vars ?

It looks like this test is failing on both Windows and Linux. Recreated the same error on the following platforms:

• XUbuntu32 running in Virtualbox on Mac (10.11)
• Raspberry Pi 2 (Debian Jessie)
• Windows 8.1 x64 in MinGW, (but possibly compiling 32 bit - will double check this later today...)

Since as you mentioned in the libmapper thread that it might be a 32/64bit variadic issue, I will give it a shot on 64 bit systems and see if it works.

For example, output from XUbuntu32:

  == test_varargs() ==
passed test_varargs (a, "/lotsofformats", "fisbmhtdSccTFNI", 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X', 'Y', LO_ARGS_END) == 0
  == test_varargs() ==
liblo error: lo_send, lo_message_add, or lo_message_add_varargs called with mismatching types and data at
testlo.c:458, exiting.
lo_message_add_varargs returned -2
passed test_varargs(a, "/lotsofformats", "f", 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X', 'Y', LO_ARGS_END) != 0
  == test_varargs() ==
liblo error: lo_send or lo_message_add called with invalid symbol pointer for arg 9, probably arg mismatch
at testlo.c:458, exiting.
lo_message_add_varargs returned -2
passed test_varargs (a, "/lotsofformats", "fisbmhtdSccTFNI", 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.5, LO_ARGS_END) != 0
passed lo_message_add(m, "fisbmhtdSccTFNI", 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt, 0.9999, "sym", 'X', 'Y') == 0
  == test_pattern() ==

Running the example TCP server with valgrind like so

examples $ valgrind --leak-check=full .libs/example_tcp_echo_server

returns unfreed blocks, when I "flood" the server with multiple subsequent requests.

==30306== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30306== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==30306== Command: .libs/example_tcp_echo_server
==30306== 
Listening on TCP port 7770
path: </hello>
==30306== Warning: invalid file descriptor -1 in syscall close()
Error sending back message, socket may have closed.
^C==30306== 
==30306== HEAP SUMMARY:
==30306==     in use at exit: 140 bytes in 2 blocks
==30306==   total heap usage: 34 allocs, 32 frees, 5,539 bytes allocated
==30306== 
==30306== 12 bytes in 1 blocks are definitely lost in loss record 1 of 2
==30306==    at 0x483777F: malloc (vg_replace_malloc.c:299)
==30306==    by 0x48514F5: lo_server_buffer_copy_for_dispatch (server.c:1036)
==30306==    by 0x4851B0F: lo_server_recv_raw_stream_socket (server.c:1214)
==30306==    by 0x4851F19: lo_server_recv_raw_stream (server.c:1333)
==30306==    by 0x48529BC: lo_server_recv (server.c:1675)
==30306==    by 0x48526D9: lo_servers_recv_noblock (server.c:1568)
==30306==    by 0x4852742: lo_server_recv_noblock (server.c:1578)
==30306==    by 0x48564B6: thread_func (server_thread.c:272)
==30306==    by 0x48E6A9C: start_thread (in /usr/lib/libpthread-2.28.so)
==30306==    by 0x4B80B22: clone (in /usr/lib/libc-2.28.so)
==30306== 
==30306== 128 bytes in 1 blocks are definitely lost in loss record 2 of 2
==30306==    at 0x48376AF: malloc (vg_replace_malloc.c:298)
==30306==    by 0x4839DE7: realloc (vg_replace_malloc.c:826)
==30306==    by 0x48516FC: lo_server_recv_raw_stream_socket (server.c:1099)
==30306==    by 0x4851F19: lo_server_recv_raw_stream (server.c:1333)
==30306==    by 0x48529BC: lo_server_recv (server.c:1675)
==30306==    by 0x48526D9: lo_servers_recv_noblock (server.c:1568)
==30306==    by 0x4852742: lo_server_recv_noblock (server.c:1578)
==30306==    by 0x48564B6: thread_func (server_thread.c:272)
==30306==    by 0x48E6A9C: start_thread (in /usr/lib/libpthread-2.28.so)
==30306==    by 0x4B80B22: clone (in /usr/lib/libc-2.28.so)
==30306== 
==30306== LEAK SUMMARY:
==30306==    definitely lost: 140 bytes in 2 blocks
==30306==    indirectly lost: 0 bytes in 0 blocks
==30306==      possibly lost: 0 bytes in 0 blocks
==30306==    still reachable: 0 bytes in 0 blocks
==30306==         suppressed: 0 bytes in 0 blocks
==30306== 
==30306== For counts of detected and suppressed errors, rerun with: -v
==30306== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

I get this result by running oscsend two subsequent times:

$ oscsend "osc.tcp://localhost:7770" /hello ; oscsend "osc.tcp://localhost:7770" /hello

You can also see that the handler only got called once.
It doesn't happen with some time between requests.
I actually have no idea what could cause it.

Neither lo.h nor lo_endian.h are copied into /usr/local/include/lo/ anymore. This becomes a problem when installing libmapper. I modified lo/Makefile.am to include these files and everything worked fine.
Should they still be there? Or is this a problem with libmapper?

I tried accessing liblo from Java using JNA (Java Native Access), but after a lot of wrestling with liblo I wrote my own wrapper lib. It turned out that the problem was, that lo_send is a macro and not a real function (https://stackoverflow.com/questions/54845785/linux-jna-unsatisfiedlinkerror-on-liblo-second-method-call/54877483#54877483).
I'm not very much into C; is there a good reason not to convert it to a 'real' function to have other languages access liblo more easily?

A method for this seems to be missing?

Hi!

I'm getting a build errors on OS X 10.10, x86_64

The errors are of the form:

../lo/lo_cpp.h:242:25: error: 'va_start' has undefined behavior with reference types [-Werror,-Wvarargs]

Perhaps it is better to use C++11 variadic functions instead of C-style variadics?

If you think this is good approach, I'd be happy to submit a pull request with a fix.

$ clang -v
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix

Hello,

lo.h has this comment for lo_address_new_with_proto:

 * Note: if you wish to receive replies from the target of this
 * address, you must first create a lo_server_thread or lo_server
 * object which will receive the replies. The last lo_server(_thread)
 * object created will be the receiver.

I am using lo_server_new_with_proto, and can't manage to receive data from the socket. My lo_server is first created (TCP, listens on port 8000), then the address (TCP, target listens on port 3032).

There is a first message to send to the target to subscribe for OSC TCP messages. I can see in the log of the client application that the subscription is made on a automatically assigned port (high number, e.g. 50462), which would indicate that the lo_address is not bound to the server port.

I looked at the source code but failed to find evidence that the last created lo_server is used as the TCP receiver. Is there something I am missing?

Thanks in advance,
Cam

running cppcheck on the liblo sources it gives me a number of errors like:

[send.c:118]: (error) va_list 'ap' was opened but not closed by va_end().

Checking on the code, I see that there are va_start() calls, but the corresponding va_end() calls are hidden deep in a called function.

This seems to use va_end() wrongly. Quoting the manpage:

va_end()
Each invocation of va_start() must be matched by a corresponding invocation of va_end() in the same function.

the important part being "in the same function".

See also https://stackoverflow.com/questions/37454179

I'm working on porting liblo to ESP32. I managed to compile and run some tests on the chip today and I'm planning to submit a pull request in the coming weeks :)

Hello! I'm working on some routing features for aiolo that rely on e1532a8 and e8408b6 which haven't been released yet. Would you be willing to release 0.31 soon? Is there anything I can help with to make that happen?

With more interest in adding file recording and playback to liblo tools (#74), it brings up interesting issues. The 1.1 spec proposes a MIME type and says that OSC should be recorded as a stream after such a header.

However, I point out in #74 that correct playback is impossible without also adding timing information. Additionally one cannot overlook the convenience of a text-equivalent format. Some more thought is required to decide how files should be handled, for liblo, but also generally for OSC.

Hi,
In this document: https://www.slideshare.net/lfevents/boost-udp-transaction-performance
author is considering the use of SO_ATTACH_REUSEPORT_CBPF for sockets in order to speed UDP transaction.
Is it something we can benefit?

++

Hi,
Is there any chance of a debian / ubuntu package of liblo ?

Cheers
S

Lot of build errors for this project. I'll need to spend more time figuring out where it's going wrong. There are a few fixes for header includes for the other tests as well but they seem to build fine after that.

It should be possible to leverage the stream support to add serial port support on all supported operating system, avoiding the need to use an external library or custom code for this common scenario of using OSC to interact with devices.

Hi!

When building 0.31 from the tarball here on github and running autoreconf -vfi on the sources leads to:

Makefile.am: error: required file './README' not found
examples/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: automake failed with exit status: 1

Symlinking README.md to README beforehand fixes this issue, but stating README.md instead of README would probably be the way to go here. :)

It should be a configuration option to allow discoverability over the zeroconf protocol as outlined in OSC 1.1 spec.

I did eventually find lo_server_set_error_context, but since I can only call it after lo_server_new returns, it seems to be too late to notice errors when creating the server.

Something like lo_server_new_with_proto_error(const char *port, int proto, lo_err_handler err_h, void *user_data) would be ugly but simple and fix it, and still more straightforward than lo_server_set_error_context.

I can send a PR if you want.

Hello,

I am using a fairly recent code base (2 commits behind master).
A user using TouchDesigner on a Mac Pro reported a crash which seems related to liblo. Looking at the crash, I infer that there is a race condition, though I may be wrong.

The crash is a segmentation fault in lo_server_next_event_delay:

Exception Type:  SIGSEGV
Exception Codes: SEGV_MAPERR at 0x0

Thread 7 Crashed:
0    0x00000001049b814d lo_server_next_event_delay (server.c:1876)
1    0x00000001049b80cd lo_servers_wait (server.c:1448)
2    0x00000001049b7d50 lo_server_wait (server.c:1350)

Looking at server.c at line 1876:

    if (s->queued) {
        lo_timetag now;
        double delay;

        lo_timetag_now(&now);
->      delay = lo_timetag_diff(((queued_msg_list *) s->queued)->ts, now);

... while another thread runs dispatch_method.

My interpretation is that something is null. The server is running so it can't be s. If it was s->queued->ts, the crash would occur in lo_timetag_diff. So it must be s->queued, but the if statement before checks for this condition, so something must change between the condition and the crash location.

I can see dispatch_queued modifies s->queued while lo_servers_wait read it (using lo_server_next_event_delay).

I am not sure if this is the problem and how to solve it.
Any idea?

Thanks for your help!

Add a way to use liblo's stream serialization over a user-provided transport mechanism.
This is already possible on a per-message basis, but liblo's packetization support could help in generalizing the mechanism, for example embedding liblo in HTTP or websockets applications.

See discussion in #75.

Hi,

i'm getting an segmentation fault when starting a server on a port which is not free at the moment (for example by starting the same binary twice). A very small example code can be found here.

My system is Ubuntu 16.04 using the following liblo-dev package: https://launchpad.net/ubuntu/xenial/amd64/liblo-dev/0.28-5

Backtrace:

#0  0x00007ffff7bd2770 in lo_server_thread_get_server () from /usr/lib/x86_64-linux-gnu/liblo.so.7
#1  0x0000000000402181 in lo::ServerThread::ServerThread(lo::num_string_type const&, void (*)(int, char const*, char const*))
    ()
#2  0x0000000000401817 in main () 

I'm trying to set up the osc-midi bridge on ubuntu for TouchOSC using pyliblo. I'm having some difficulty with configuration.

autoconf gives

configure.ac:29: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:30: error: possibly undefined macro: AM_MAINTAINER_MODE
configure.ac:33: error: possibly undefined macro: AC_ENABLE_STATIC
configure.ac:34: error: possibly undefined macro: AC_ENABLE_SHARED
configure.ac:53: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
configure.ac:54: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:55: error: possibly undefined macro: AM_PROG_CC_C_O
configure.ac:112: error: possibly undefined macro: AM_CONDITIONAL

./configure gives

./configure: line 2240: AM_INIT_AUTOMAKE: command not found
./configure: line 2241: AM_MAINTAINER_MODE: command not found
./configure: line 2244: syntax error near unexpected token no' ./configure: line 2244:AC_ENABLE_STATIC(no)'

Guessing there is some build tool dependency that I'm missing

I will look into this issue. Help or tips much appreciated.

liblo-0.29

server.c: In function ‘lo_server_resolve_hostname’:
server.c:303:10: error: ‘it’ undeclared (first use in this function)
     for (it = ai; it; it = it->ai_next) {
          ^~
server.c:303:10: note: each undeclared identifier is reported only once for each function it appears in
server.c:303:15: error: ‘ai’ undeclared (first use in this function)
     for (it = ai; it; it = it->ai_next) {
               ^~

With tightened builds flags on Fedora with gcc8 I get the following builds failure on 0.29:

server.c: In function 'lo_server_resolve_hostname':
server.c:303:10: error: 'it' undeclared (first use in this function); did you mean 'int'?
     for (it = ai; it; it = it->ai_next) {
          ^~
          int
server.c:303:10: note: each undeclared identifier is reported only once for each function it appears in
server.c:303:15: error: 'ai' undeclared (first use in this function)
     for (it = ai; it; it = it->ai_next) {
               ^~
make[3]: *** [Makefile:824: liblo_la-server.lo] Error 1
make[3]: *** Waiting for unfinished jobs....

lo_cpp.h has a #include <cassert> inside the lo namespace declaration, which results in the necessary declarations being inaccessible to anything that includes lo_cpp.h before its own inclusion of <cassert> due to the preprocessor multiple-inclusion guard.

I've submitted #99 as a suggested fix, moving the necessary #include to the top of the file and leaving the rest of the declarations in place.

Greetings!

I'm compiling liblo-0.30 under a Clear Linux Project system.

✔️ No errors while running ./configure 😄

⚠️ But I get this while running ./sudo make install 🤕

Making install in src
make[1]: Entering directory '/home/milk_man/Downloads/liblo-0.30/src'
Making install in .
make[2]: Entering directory '/home/milk_man/Downloads/liblo-0.30/src'
make[3]: Entering directory '/home/milk_man/Downloads/liblo-0.30/src'
 /usr/bin/mkdir -p '/usr/local/lib'
 /bin/sh ../libtool   --mode=install /usr/bin/install -c   liblo.la '/usr/local/lib'
libtool: install: /usr/bin/install -c .libs/liblo.so.7.4.0 /usr/local/lib/liblo.so.7.4.0
libtool: install: (cd /usr/local/lib && { ln -s -f liblo.so.7.4.0 liblo.so.7 || { rm -f liblo.so.7 && ln -s liblo.so.7.4.0 liblo.so.7; }; })
libtool: install: (cd /usr/local/lib && { ln -s -f liblo.so.7.4.0 liblo.so || { rm -f liblo.so && ln -s liblo.so.7.4.0 liblo.so; }; })
libtool: install: /usr/bin/install -c .libs/liblo.lai /usr/local/lib/liblo.la
libtool: finish: PATH="/usr/local/bin:/usr/bin/haswell:/usr/bin:/opt/3rd-party/bin:/sbin" ldconfig -n /usr/local/lib
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the 'LD_RUN_PATH' environment variable
     during linking
   - use the '-Wl,-rpath -Wl,LIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
make[3]: Nothing to be done for 'install-data-am'.
make[3]: Leaving directory '/home/milk_man/Downloads/liblo-0.30/src'
make[2]: Leaving directory '/home/milk_man/Downloads/liblo-0.30/src'
Making install in tools
make[2]: Entering directory '/home/milk_man/Downloads/liblo-0.30/src/tools'
Making install in .
make[3]: Entering directory '/home/milk_man/Downloads/liblo-0.30/src/tools'
  CC       oscsend-oscsend.o
  CCLD     oscsend
  CC       oscdump-oscdump.o
  CCLD     oscdump
  CC       oscsendfile-oscsendfile.o
oscsendfile.c: In function ‘send_file’:
oscsendfile.c:251:8: error: ‘tt_start_file.frac’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  251 |     if (tt->frac < subtrahend.frac) // overflow
      |        ^
oscsendfile.c:280:35: note: ‘tt_start_file.frac’ was declared here
  280 |     lo_timetag tt_start = {0, 0}, tt_start_file, tt_now;
      |                                   ^~~~~~~~~~~~~
oscsendfile.c:280:35: error: ‘tt_start_file.sec’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
make[3]: *** [Makefile:533: oscsendfile-oscsendfile.o] Error 1
make[3]: Leaving directory '/home/milk_man/Downloads/liblo-0.30/src/tools'
make[2]: *** [Makefile:559: install-recursive] Error 1
make[2]: Leaving directory '/home/milk_man/Downloads/liblo-0.30/src/tools'
make[1]: *** [Makefile:965: install-recursive] Error 1
make[1]: Leaving directory '/home/milk_man/Downloads/liblo-0.30/src'
make: *** [Makefile:470: install-recursive] Error 1

This seems to be the problem...

oscsendfile.c: In function ‘send_file’:
oscsendfile.c:251:8: error: ‘tt_start_file.frac’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  251 |     if (tt->frac < subtrahend.frac) // overflow
      |        ^
oscsendfile.c:280:35: note: ‘tt_start_file.frac’ was declared here
  280 |     lo_timetag tt_start = {0, 0}, tt_start_file, tt_now;
      |                                   ^~~~~~~~~~~~~
oscsendfile.c:280:35: error: ‘tt_start_file.sec’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

Any ideas what it could be? 🤔

Thanks! 👨‍🚀 🤝

I observed a Segfault when using oscsend.
I could track it down to is_local_broadcast()in send.c. It seems that in rare cases ifa->ifa_addr can be NULL in the loop. Breaking out of the loop if it was NULL solved the issue for me.

diff --git a/src/send.c b/src/send.c
index 900ec99..6fab03c 100644
--- a/src/send.c
+++ b/src/send.c
@@ -332,6 +332,7 @@ static int is_local_broadcast(struct addrinfo *ai){
 
     // loop over all network interfaces
     for (ifa = ifap; ifa; ifa = ifa->ifa_next) {
+        if (ifa->ifa_addr==NULL) {break;}
         if (ifa->ifa_addr->sa_family==AF_INET) {
             // get this machine's address for the current interface (ie. 192.168.1.6)
             uint32_t cur_addr = ((struct sockaddr_in *) ifa->ifa_addr)->sin_addr.s_addr;

looking at how liblo deals with multiple results from getaddrinfo(), i see that in the case of UDP, you just try to send to each of the results until one succeeds.

however, there seems to be the same logic applied to the TCP/IP case, which i reproduce here for your own ease:

do {
  ret = send(sock, data, len, MSG_NOSIGNAL);
  if (a->protocol == LO_TCP)
    ai = ai->ai_next;
  else
    ai = 0;
} while (ret == -1 && ai != NULL);

This looks slightly bogus to me, as you keep sending to the same socket sock: if you the send fails, you repeat sending to the very same address (the number of repeats is determined by the results from getaddrinfo()).

otoh, when creating the socket (create_socket()) you just try the very first result (but you could iterate over all until you find one that works)

It is currently impossible to use the lo_cpp.h header in two different translation units. Each time lo_cpp.h is included, it imports a few functions, which results in multiple definitions.

Example:

a.h:

#ifndef AH
#define AH
#include <lo_cpp.h>
void func(lo::Message);  
#endif AH

a.cpp

#include "a.h"
void func(lo::Message){
  ....
}

b.cpp

#include "a.h"
int main(){
  func(...);
}

Compilation succeeds, linking fails, because the following functions have double definitions:

std::string version();
lo_timetag now();
lo_timetag immediate();
int Address::send_from(lo::ServerThread &from, const string_type &path, const string_type &type, ...);
int Address::send_from(lo::ServerThread &from, lo_bundle b);

and indeed that is the case, as these functions have out of class definitions inside lo_cpp.h. This is wrong, as that is not the point of header files.

No in-source tests are detecting this issue, because they all use a single translation unit.

Possible solution would be to convert these definitions into in-class definitions, if possible. Another option would be to move these definitions to a separate header file, which would be then included on developer's demand. Yet another solution would be to wrap these definitions in a preprocesor #ifndef directive, so that it is possible to manualy deactivate them.

I believe this bug is of high severity, beause it makes it impossible to use the C++ liblo API in any serious application that is made of more than a single file. A temporary workaround is to remove the offending function definitions from the header file.

Hi,
could you please bump up the version number? Otherwise at least Fedora won't update their package which makes the C++ interface that is shipped with Fedora mostly unusable.

Thanks,
Felix

Currently, AFAICT the only way to remove a method from a server is
void lo_server_del_method(lo_server s, const char *path, const char *typespec)

This way you would end up deleting every method that matches the path and typespec. If you have more than one method matching both all of them would be deleted from the server.

I'd like to be able to delete only a specific method e.g. by introducing

void lo_server_del_method(lo_server s, lo_method method, const char *path, const char *typespec)

So you can keep track of the methods an delete them selectively.
This would allow for much more dynamic method usage.

PS.: After looking into the source code it seems that path and typespec are already stored in a lo_method, so

void lo_server_del_method(lo_server s, lo_method method)

should already contain all needed information to delete a method.

Kind regards,
Felix

I've created a PR to add this to VCPKG here: microsoft/vcpkg#2821

If you wanted to take a look or make any changes. Cheers!

56cec7e

This commit added the code "if (memcmp(&tt, &LO_TT_IMMEDIATE, sizeof(lo_timetag))==0) {" which fails to compile with Visual Studio. Any chance this could be looked at?

2>oscdump.c
2>C:\Users\skyne\Source\Repos\liblo\src\tools\oscdump.c(54): error C2102: '&' requires l-value
2>C:\Users\skyne\Source\Repos\liblo\src\tools\oscdump.c(88): error C2102: '&' requires l-value

Hi,

The liblo git comes without the generated files which is good. Question is, if I run "autogen.sh" on a Mac, will the generated "lo.h" (and any other relevant generated files) be valid on Windows?

Hi,
I've been playing around with the Behringer's X32-Edit software for controlling the X32 series digital mixers (in preparation of a possible purchase). oscdump shows "liblo server error 9902 in path /info: Invalid message received". According to the documentation[1] of their OSC protocol the message send to info /info should be nil but obviously the Type Tag String is missing in their implementation.

The OSC 1.0 specs[2] say about it:
"OSC Messages
An OSC message consists of an OSC Address Pattern followed by an OSC Type Tag String followed by zero or more OSC Arguments.

Note: some older implementations of OSC may omit the OSC Type Tag string. Until all such implementations are updated, OSC implementations should be robust in the case of a missing OSC Type Tag String."

So, obviously liblo is not robust against missing OSC Type Tag Strings. It would be great if missing types could just be handled like 'nil' types so that liblo is able to talk with other (yes, I know they are wrong) implementations.

Thanks and kind regards,
Felix

[1] http://www.behringer.com/assets/X32_OSC_Remote_Protocol.pdf
[2] http://opensoundcontrol.org/spec-1_0

Hello,

I've been at this for 2 days, and I'm really at a loss here, without delving into the lib inards, I won't be able to figure this out, meybe it's actualy a bug or it's me being dumb...

I have the following code, it's an example just to cause the segfault, trying to keep it simple

#include <iostream>
#include <lo/lo.h>
#include <lo/lo_cpp.h>

lo::Address toB("192.168.1.60", 10023);

int AtoB_generic_handler(const char *path, const char *types, lo_arg **argv,
                          int argc, lo_message m, void *data)
{
    std::cout << "Local Got message " << path << std::endl;
    std::cout << "Local Msg ";
    lo_message_pp(m);

    lo::ServerThread *server = reinterpret_cast<lo::ServerThread*>(data);
    toB.send_from(server, path, m);

    return 1; 
}

int main(int, char**)
{
    lo::ServerThread AtoB(10023);
    lo::ServerThread BtoA(11023);

    if(!AtoB.is_valid())
    {
        std::cout << "AtoB Invalid" << std::endl;
        return 1;
    }

    if(!BtoA.is_valid())
    {
        std::cout << "BtoA Invalid" << std::endl;
        return 1;
    }

    AtoB.add_method(NULL, NULL, AtoB_generic_handler, &BtoA);

    AtoB.start();

    while(1){}
}

I tried several ways of handling the send_from, even built a queue, fill the queue in the callback, and process the queue and send_from in main loop but the result is the same, there's a segfault in send_data as per the backtrace below

Thread 5 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6168.0x1b1c]
0x0000000000405bc4 in send_data (a=0x7d1ee0, from=0x6bfd00, data=0x6d2da0 "/renew", data_len=24) at .... \ext\liblo\src\send.c:474
474             sock = from->sockets[0].fd;
(gdb) bt
#0  0x0000000000405bc4 in send_data (a=0x7d1ee0, from=0x6bfd00, data=0x6d2da0 "/renew", data_len=24) at .... \ext\liblo\src\send.c:474
#1  0x0000000000405fed in lo_send_message_from (a=0x7d1ee0, from=0x6bfd00, path=0x7d1ab0 "/renew", msg=0x6d2bb0) at .... \ext\liblo\src\send.c:576
#2  0x000000000040f3f7 in lo::Address::send_from (this=0x418030 <to>, from=0x6bfd00, path=..., m=0x6d2bb0) at .... /ext/liblo/lo/lo_cpp.h:258
#3  0x00000000004015fe in AtoB_generic_handler (path=0x7d1ab0 "/renew", types=0x6d2c31 "s", argv=0x6d2cb0, argc=1, m=0x6d2bb0, data=0x6bfd00) at .... \main.cpp:15
#4  0x0000000000409eba in dispatch_method (s=0x6d24b0, path=0x7d1ab0 "/renew", msg=0x6d2bb0, sock=-1) at .... \ext\liblo\src\server.c:1942
#5  0x0000000000409bb8 in dispatch_data (s=0x6d24b0, data=0x7d1ab0, size=24, sock=-1) at .... \ext\liblo\src\server.c:1866
#6  0x000000000040937e in lo_server_recv (s=0x6d24b0) at .... \ext\liblo\src\server.c:1693
#7  0x0000000000408f90 in lo_servers_recv_noblock (s=0x294fe90, recvd=0x294fe7c, num_servers=1, timeout=10) at ... \ext\liblo\src\server.c:1577
#8  0x0000000000408fec in lo_server_recv_noblock (s=0x6d24b0, timeout=10) at... \ext\liblo\src\server.c:1587
#9  0x000000000040b62d in thread_func (data=0x7d2010) at .... \ext\liblo\src\server_thread.c:278
#10 0x00007ff8c30bb04a in msvcrt!_beginthreadex () from C:\WINDOWS\System32\msvcrt.dll
#11 0x00007ff8c30bb11c in msvcrt!_endthreadex () from C:\WINDOWS\System32\msvcrt.dll
#12 0x00007ff8c4207bd4 in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\System32\kernel32.dll
#13 0x00007ff8c4ecce51 in ntdll!RtlUserThreadStart () from C:\WINDOWS\SYSTEM32\ntdll.dll
#14 0x0000000000000000 in ?? ()

Im using mingw (64bit) on windows, will try in a linux machine and see if the problem remains, any pointers on how to proceed to fix this ?

Regards.

With the following error:

gcc -DHAVE_CONFIG_H -I. -I../..     -I../.. -O0 -g -Wall -Werror -DDEBUG -MT oscdump
-oscdump.o -MD -MP -MF .deps/oscdump-oscdump.Tpo -c -o oscdump-oscdump.o `test -f 'oscdump.c' || echo './'`oscdump.c
oscdump.c: In function ‘main’:
oscdump.c:86:5: error: array subscript has type ‘char’ [-Werror=char-subscripts]
     } else if (isdigit(port[0])) {
     ^
cc1: all warnings being treated as errors
Makefile:479: recipe for target 'oscdump-oscdump.o' failed
make[4]: *** [oscdump-oscdump.o] Error 1
make[4]: Leaving directory '/home/user/projects/liblo/liblo-0.28/src/tools'
Makefile:519: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/user/projects/liblo/liblo-0.28/src/tools'
Makefile:949: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/user/projects/liblo/liblo-0.28/src'
Makefile:457: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/user/projects/liblo/liblo-0.28'
Makefile:365: recipe for target 'all' failed
make: *** [all] Error 2

I was able to fix the error with a cast, changing:
} else if (isdigit(port[0])) {
to:
} else if (isdigit((int)port[0])) {
However, I'm not familiar enough with the language to say for certain that this is the best way to go about it, so I thought it best to hold off on making a PR for it.

Hi guys,

I submitted a pull request to get the CMake build working on Windows. Any chance this could be incorporated into the repo?

As it stands, I can't really get it building with premake or cmake without manual modification to the produced solution files.

Thanks

Hi,
I am attempting to use liblo to send some large messages (binary data of images really), and I'm running into some issues with larger images. Specifically the following code fails with failSize set to 32753, but works properly when using a message size of 32752.

//for liblo
#include "lo/lo.h"

//for printf
#include <stdio.h>


int main(int argc, char ** argv)
{

    long long int failSize = 32753;

    const char * host = "localhost";

    const char * port = "7000";

    const char * path = "/test2";

    //make an address object
    lo_address destAddr = lo_address_new_with_proto(LO_TCP,host,port);

    //make a new message
    lo_message message = lo_message_new();

    //allocate memory for the data
    unsigned char * data = (unsigned char *) calloc(failSize,sizeof(unsigned char));

    //fill the array with test data
    int index = 0;
    for(index = 0; index < failSize; index++)
        data[index] = index;

    lo_blob myBlob = lo_blob_new(failSize,(void *)data);

    //put the blob into the message
    lo_message_add_blob(message,myBlob);

    //free the blob
    lo_blob_free(myBlob);

    //free our copy of the data too
    free(data);

    //send the message
    int sendResult = lo_send_message(destAddr,path,message);
    if(sendResult < 0)
    {
        //send failed
        printf("failed to send message\n");
        printf("errno : %s (%d) \n",strerror(lo_address_errno(destAddr)),lo_address_errno(destAddr));
        printf("message length was : %lld\n",failSize);
    }
    else
    {
        printf("sent message successfully\n");
    }

    //free the message
    lo_message_free(message);
}

Running this on my machine produces:

failed to send message
errno : Not a STREAM (99) 
message length was : 32753

I was under the impression that with TCP there wasn't an upper limit on message sizes? I am only sending one argument, a binary blob.

This seems related to #41 but still occurs on current master.

Starting two ServerThreads using the same port causes a Segmentation fault.

#include <lo/lo.h>
#include <lo/lo_cpp.h>

int main(){
    lo::ServerThread st(9000);
    lo::ServerThread st2(9000);
    st.start();
    st2.start();
}

Since I don't see a way to query for the port numbers already in use via liblo (of course not), this becomes quite troublesome when allowing the user to both create multiple instances of an application and, at the same time, to customize the OSC port used.

I have cloned the repository, but when I run either "./configure" or "sh ./configure" I get an error:

configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'

Same error occurs for the command "./autogen.sh"

When building on msvc2013 using cmake the add_method template code fails with many errors of this kind:

C:\Users\swnc\Documents\development\src\liblo\lo/lo_cpp.h(521): error C2572: 'lo::Server::add_method' : redefinition of default parameter : parameter 4
C:\Users\swnc\Documents\development\src\liblo\lo/lo_cpp.h(515) : see declaration of 'lo::Server::add_method'
C:\Users\swnc\Documents\development\src\liblo\lo/lo_cpp.h(521): error C2535: 'lo::Method lo::Server::add_method(const lo::string_type,const lo::string_type,H &&,std::enable_if<std::is_same<unknown-type,int>::value,void>::type *)' : member function already defined or declared
C:\Users\swnc\Documents\development\src\liblo\lo/lo_cpp.h(515) : see declaration of 'lo::Server::add_method'
C:\Users\swnc\Documents\development\src\liblo\lo/lo_cpp.h(521): error C2548: 'lo::Server::add_method' : missing default parameter for parameter 4

and

C:\Users\swnc\Documents\development\src\liblo\src\cpp_test.cpp(66): error C2660: 'lo::Server::add_method' : function does not take 3 arguments
C:\Users\swnc\Documents\development\src\liblo\src\cpp_test.cpp(70): error C2660: 'lo::Server::add_method' : function does not take 3 arguments

It builds fine with msvc2017 so this is just for the record.

Hello, thanks so much to all the authors of this library, I'm looking forward to using it in my audio projects.

I've written Python bindings for liblo with some nice features that I think other folks would appreciate, such as asyncio support, a routing API, a publish-subscribe pattern, an extensive test suite, and both CPython and PyPy support.

Would you be open to adding a link to aiolo on the liblo homepage to help people find it?

If a small value is sent as a float or double, it's likely that for instance oscdump using lo_arg_pp will display 0.00000.
Please see attached patch as a possible addition in lo_arg_pp_internal.
-Displays small floats and doubles using scientific notation if the value is <=0.0001.
-Add missing (?) ' for symbol display. I wasn't 100% if it's missing or if a single ' helps to distinguish from the 'c' type. Since the typestring will indicate the difference, enclosing LO_SYMBOL with ' seemed sane.

message.c.diff.txt

Current there are some failures with IPv6 support. It is not easy to solve, so if anyone wants to help it's a nice challenge.

Firstly, it's not clear to me how multicast works with IPv6, so test_multicast() fails. There are a couple of TODO notes in the source regarding this. Specifically,

setsockopt(s->sockets[0].fd, IPPROTO_IP, IPV6_MULTICAST_IF,                  
                   &s->addr_if.a.addr6, s->addr_if.size

appears to return an error on Linux.

However, if you compile with --enable-ipv6 and comment-out test_multicast(), there are still some errors in basic liblo functionality when communicating with the subtest subprocess.

subtest: creating new address `osc.udp://bicycle15:17776/'
 <-- subtest_handler()
subtest: got reply (/subtest)
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
 <-- subtest_reply_handler()
FAILED reply_count == 3 at testlo.c:1441

test run not completed
liblo test FAILED

Hi,

Is it possible to use the premake4 build flow to generate a Visual Studio project that will build liblo for Windows for a 64-bit architecture?

Apologies if I've missed something obvious, but the premake lua file seems pretty specialized to 32-bit windows. I've never developed for Windows before and I'm using an environment that only supports building via Visual Studio.

Thanks!

Right now I do not see a way to send a Bundle from a ServerThread. It seems that is missing in the implementation?