liblo-devel Mailing List for LibLO

Hello Mark,

On 29 sept. 2013, at 16:20, "Mark D. McCurry" <mar...@gm...> wrote:

>> I am using a PIC32 from Microchip with the XC32 compiler on MPLAB X.
>> Before I do, I was wondering if there was not a better approach.
>> Your suggestions are welcome, thanks!
> 
> Taking a quick glance at the hardware it might make sense to try to avoid
> dynamic memory depending on how much else is going on within the chip.
> Looking at the linked code malloc/free are around in a few places, though that
> might not be an issue with 64kb of ram.
> If you're trying to avoid the heap and you're not doing much in the way of
> dispatching, then something like the C core of https://github.com/fundamental/rtosc
> might be more appliciable.

Thank you Mark for making this library available.
I was looking for a similar solution.
I think it will be perfect for my initial needs.


> If your compiler supports a few bits of C99, then it might be sufficient to just
> copy the basics code out of https://github.com/fundamental/rtosc/blob/master/src/rtosc.c
> Note, that I have not yet tried it, but I intend to attempt to fit the lib on
> some avr chips (eventually) with a much much smaller ram and slightly smaller
> code space.

I have some PIC16 and PIC18 that I can try too.
As they do not support malloc (I think), this library comes in very handy.


Best,
Cam

> I am using a PIC32 from Microchip with the XC32 compiler on MPLAB X.
> Before I do, I was wondering if there was not a better approach.
> Your suggestions are welcome, thanks!

Taking a quick glance at the hardware it might make sense to try to avoid
dynamic memory depending on how much else is going on within the chip.
Looking at the linked code malloc/free are around in a few places, though that
might not be an issue with 64kb of ram.
If you're trying to avoid the heap and you're not doing much in the way of
dispatching, then something like the C core of https://github.com/fundamental/rtosc
might be more appliciable.
If your compiler supports a few bits of C99, then it might be sufficient to just
copy the basics code out of https://github.com/fundamental/rtosc/blob/master/src/rtosc.c
Note, that I have not yet tried it, but I intend to attempt to fit the lib on
some avr chips (eventually) with a much much smaller ram and slightly smaller
code space.

Hopefully a bit of advertisement is fine on this list.

--Mark

Hi Steve,


> On 29 sept. 2013, at 14:51, Stephen Sinclair <rad...@gm...> wrote:
> 
> If it works on a microcontroller it's news to me!! Let me know how it goes.

I got a modified version to compile without networking support. Now I must work on the networking side to do start testing.


> Does the PIC32 environment support the POSIX socket API?

Not really, there is what they call the Berkley sockets, that look a lot like POSIX sockets but I wouldn't try it.


> For μC environments, I always thought that it should be possible to
> disable the networking aspects of liblo and use only
> lo_message_serialise()/deserialise(), but it's rather entwined in
> there.

Yes this is what I want to do.  I only spent an hour this morning, doing this cleanly should take a couple of days.


> I think someone did make a fork of liblo at some point with
> some networking aspects removed.  Ah, found it:
> 
> https://github.com/milkymist/liboscparse

That's interesting, I will have a look, thanks!

Best,
Camille

On Sat, Sep 28, 2013 at 6:54 PM, Camille Troillard
<ca...@os...> wrote:
> Hello,
>
> I think I saw it previously discussed on this list, but I thought it would be useful to round up the steps on how to configure liblo for a micro-controller.  Specifically, I am using a PIC32 from Microchip with the XC32 compiler on MPLAB X.
>
> As I have no exact idea on what to do, I am going to run ./configure on my Mac, and customize the settings based on what I know from the micro controller (endianness, integer and pointer size, etc.).
>
> Before I do, I was wondering if there was not a better approach.
> Your suggestions are welcome, thanks!
>

If it works on a microcontroller it's news to me!! Let me know how it goes.
Does the PIC32 environment support the POSIX socket API?
For μC environments, I always thought that it should be possible to
disable the networking aspects of liblo and use only
lo_message_serialise()/deserialise(), but it's rather entwined in
there.  I think someone did make a fork of liblo at some point with
some networking aspects removed.  Ah, found it:

https://github.com/milkymist/liboscparse

Steve

Hello,

I think I saw it previously discussed on this list, but I thought it would be useful to round up the steps on how to configure liblo for a micro-controller.  Specifically, I am using a PIC32 from Microchip with the XC32 compiler on MPLAB X.

As I have no exact idea on what to do, I am going to run ./configure on my Mac, and customize the settings based on what I know from the micro controller (endianness, integer and pointer size, etc.).

Before I do, I was wondering if there was not a better approach.
Your suggestions are welcome, thanks!


Best,
Camille

On Thu, Sep 5, 2013 at 6:30 PM, Felipe Sateler <fsa...@gm...> wrote:
> On Thu, Sep 5, 2013 at 5:10 AM, Stephen Sinclair <rad...@gm...> wrote:
>> On Tue, Sep 3, 2013 at 2:42 AM, Felipe Sateler <fsa...@de...> wrote:
>>> On Mon, Sep 2, 2013 at 8:16 PM, Felipe Sateler <fsa...@de...> wrote:
>>>> On Mon, Sep 2, 2013 at 7:33 PM, Felipe Sateler <fsa...@de...> wrote:
>>>>> Hi liblo devs,
>>>>>
>>>>> The python liblo wrapper has a test suite that has uncovered a bug in
>>>>> liblo.
>>>>
>>>> I just tried current git (5a7a54b4a0a) and the test provided by
>>>> Sebastian continues to fail.
>>>
>>> It appears the problem is that in sparc, you can't just say
>>> *(datatype*)data. Depending on datatype, 'data' has to be aligned at a
>>> certain number of bytes from the original block (4 for int, 8 for
>>> int64):
>>>
>>> char* src = something();
>>> int* tmp = (int*)(src + 1); // If 1 is replaced by 4, no bus error.
>>> *src = 1; // Bus error here.
>>> int a = *src; // This yields bus error too
>>>
>>> So, at least lo_message_add_data (plus all its users),
>>> lo_arg_pp_internal and lo_arg_host_endian need to change to support
>>> sparc.
>>>
>>
>> Any idea how to get a sparc test environment running?  Is there an
>> emulator I can use for example?
>
> QEMU should support sparc targets. I believe qemu-system-sparc is the
> package (in Debian) you can use to create a sparc system. At [1] there
> appear to be instructions for setting up a debian qemu sparc system.
> Alternatively, we could request access for you on some debian porter
> machine. This could take a while, though, and requires some steps to
> be taken[2]

Okay, thank you.  I have tried for some time today to get
qemu-system-sparc running actually, and ran into a problem where the
bios works but then it boots to a black screen and doesn't display the
debian installer.

In any case, I'll try some more to get it working before resorting to
complicated administrative measures :)

On Thu, Sep 5, 2013 at 5:10 AM, Stephen Sinclair <rad...@gm...> wrote:
> On Tue, Sep 3, 2013 at 2:42 AM, Felipe Sateler <fsa...@de...> wrote:
>> On Mon, Sep 2, 2013 at 8:16 PM, Felipe Sateler <fsa...@de...> wrote:
>>> On Mon, Sep 2, 2013 at 7:33 PM, Felipe Sateler <fsa...@de...> wrote:
>>>> Hi liblo devs,
>>>>
>>>> The python liblo wrapper has a test suite that has uncovered a bug in
>>>> liblo.
>>>
>>> I just tried current git (5a7a54b4a0a) and the test provided by
>>> Sebastian continues to fail.
>>
>> It appears the problem is that in sparc, you can't just say
>> *(datatype*)data. Depending on datatype, 'data' has to be aligned at a
>> certain number of bytes from the original block (4 for int, 8 for
>> int64):
>>
>> char* src = something();
>> int* tmp = (int*)(src + 1); // If 1 is replaced by 4, no bus error.
>> *src = 1; // Bus error here.
>> int a = *src; // This yields bus error too
>>
>> So, at least lo_message_add_data (plus all its users),
>> lo_arg_pp_internal and lo_arg_host_endian need to change to support
>> sparc.
>>
>
> Any idea how to get a sparc test environment running?  Is there an
> emulator I can use for example?

QEMU should support sparc targets. I believe qemu-system-sparc is the
package (in Debian) you can use to create a sparc system. At [1] there
appear to be instructions for setting up a debian qemu sparc system.
Alternatively, we could request access for you on some debian porter
machine. This could take a while, though, and requires some steps to
be taken[2]


[1] http://tyom.blogspot.com/2013/03/debiansparc64-wheezy-under-qemu-how-to.html
[2] http://dsa.debian.org/doc/guest-account/

>
> In the provided stack traces the "data" variable does seem to be
> 4-byte aligned, but the error is on a 64-bit data type.  I am curious
> to know if this problem _only_ occurs for 64-bit types?
>
> Type-casting is somewhat fundamental to how liblo uses the lo_arg data
> structure and for interpreting raw memory blocks of OSC data.  In
> general OSC is by-design 32-bit-aligned, so generally this shouldn't
> be an issue, but if there are cases where things need to be
> 64-bit-aligned I can see how this problem might creep in.

I'm definitely no expert, but my googling leaves me with the
impression that every native type (sizes 1, 2, 4 and 8 bytes) has a
dedicated instruction that requires data to be 1,2,4 or 8 bytes
aligned. So errors should only happen with 64 bit types if OSC is
32-bit aligned.


-- 

Saludos,
Felipe Sateler

On Tue, Sep 3, 2013 at 2:42 AM, Felipe Sateler <fsa...@de...> wrote:
> On Mon, Sep 2, 2013 at 8:16 PM, Felipe Sateler <fsa...@de...> wrote:
>> On Mon, Sep 2, 2013 at 7:33 PM, Felipe Sateler <fsa...@de...> wrote:
>>> Hi liblo devs,
>>>
>>> The python liblo wrapper has a test suite that has uncovered a bug in
>>> liblo.
>>
>> I just tried current git (5a7a54b4a0a) and the test provided by
>> Sebastian continues to fail.
>
> It appears the problem is that in sparc, you can't just say
> *(datatype*)data. Depending on datatype, 'data' has to be aligned at a
> certain number of bytes from the original block (4 for int, 8 for
> int64):
>
> char* src = something();
> int* tmp = (int*)(src + 1); // If 1 is replaced by 4, no bus error.
> *src = 1; // Bus error here.
> int a = *src; // This yields bus error too
>
> So, at least lo_message_add_data (plus all its users),
> lo_arg_pp_internal and lo_arg_host_endian need to change to support
> sparc.
>

Any idea how to get a sparc test environment running?  Is there an
emulator I can use for example?

In the provided stack traces the "data" variable does seem to be
4-byte aligned, but the error is on a 64-bit data type.  I am curious
to know if this problem _only_ occurs for 64-bit types?

Type-casting is somewhat fundamental to how liblo uses the lo_arg data
structure and for interpreting raw memory blocks of OSC data.  In
general OSC is by-design 32-bit-aligned, so generally this shouldn't
be an issue, but if there are cases where things need to be
64-bit-aligned I can see how this problem might creep in.

Suggestions on how to debug would be useful as I am completely
unfamiliar with sparc.

thanks,
Steve

On Mon, Sep 2, 2013 at 8:16 PM, Felipe Sateler <fsa...@de...> wrote:
> On Mon, Sep 2, 2013 at 7:33 PM, Felipe Sateler <fsa...@de...> wrote:
>> Hi liblo devs,
>>
>> The python liblo wrapper has a test suite that has uncovered a bug in
>> liblo.
>
> I just tried current git (5a7a54b4a0a) and the test provided by
> Sebastian continues to fail.

It appears the problem is that in sparc, you can't just say
*(datatype*)data. Depending on datatype, 'data' has to be aligned at a
certain number of bytes from the original block (4 for int, 8 for
int64):

char* src = something();
int* tmp = (int*)(src + 1); // If 1 is replaced by 4, no bus error.
*src = 1; // Bus error here.
int a = *src; // This yields bus error too

So, at least lo_message_add_data (plus all its users),
lo_arg_pp_internal and lo_arg_host_endian need to change to support
sparc.


-- 

Saludos,
Felipe Sateler

On Mon, Sep 2, 2013 at 7:33 PM, Felipe Sateler <fsa...@de...> wrote:
> Hi liblo devs,
>
> The python liblo wrapper has a test suite that has uncovered a bug in
> liblo.

I just tried current git (5a7a54b4a0a) and the test provided by
Sebastian continues to fail:

Program received signal SIGBUS, Bus error.
0xf7fb0e5c in lo_arg_pp_internal (type=LO_STRING, data=0x22e94, bigendian=0)
    at message.c:1021
1021            val64.nl = *(int64_t *) data;
(gdb) bt
#0  0xf7fb0e5c in lo_arg_pp_internal (type=LO_STRING, data=0x22e94,
    bigendian=0) at message.c:1021
#1  0xf7fb0d44 in lo_arg_pp (type=LO_STRING, data=0x22e94) at message.c:993
#2  0x0001082c in messageHandler (path=0x22728 "/test", types=0x22781 "hTfs",
    argv=0x22ea0, argc=4, msg=0x22750, user_data=0x0) at oscdump.c:61
#3  0xf7fb5aec in dispatch_method (s=0x22008, path=0x22728 "/test",
    msg=0x22750, sock=-1) at server.c:1746
#4  0xf7fb56c0 in dispatch_data (s=0x22008, data=0x22728, size=36, sock=-1)
    at server.c:1670
#5  0xf7fb4cf8 in lo_server_recv (s=0x22008) at server.c:1498
#6  0x00010a1c in main (argc=2, argv=0xffffdcb4) at oscdump.c:105


Moreover, the testsuite also fails, but in a different place:

Program received signal SIGBUS, Bus error.
lo_message_add_int64 (m=0x2c730, a=81985529216486895) at message.c:368
368    *nptr = b.nl;
(gdb) bt
#0  lo_message_add_int64 (m=0x2c730, a=81985529216486895) at message.c:368
#1  0x00012bdc in test_deserialise () at testlo.c:1040
#2  0x000154d0 in main () at testlo.c:149


Tried several gcc versions, all fail.

-- 

Saludos,
Felipe Sateler

Hi liblo devs,

The python liblo wrapper has a test suite that has uncovered a bug in
liblo. More details below:

On Mon, Sep 2, 2013 at 1:56 PM, Sebastian Ramacher <sra...@de...> wrote:
>
> On 2013-09-02 14:51:18, Sebastian Ramacher wrote:
>> Source: pyliblo
>> Version: 0.9.1-3
>> Severity: serious
>> Justification: FTBFS but built successfully in the past
>>
>> pyliblo FTBFS on sparc:
>> | PYTHONPATH=$(ls -d /home/sramacher/pyliblo-0.9.1/build/lib.*-2.7) \
>> |                 python2.7 -m unittest discover -s test/ -p '*.py' -v
>> | testHostPort (unit.AddressTestCase) ... ok
>> | testHostPortProto (unit.AddressTestCase) ... ok
>> | testPort (unit.AddressTestCase) ... ok
>> | testUrl (unit.AddressTestCase) ... ok
>> | testSendReceive (unit.DecoratorTestCase) ... ok
>> | testNoPermission (unit.ServerCreationTestCase) ... ok
>> | testPort (unit.ServerCreationTestCase) ... ok
>> | testPortProto (unit.ServerCreationTestCase) ... ok
>> | testRandomPort (unit.ServerCreationTestCase) ... ok
>> | testNotReachable (unit.ServerTCPTestCase) ... ok
>> | testSendReceive (unit.ServerTCPTestCase) ... ok
>> | testPort (unit.ServerTestCase) ... ok
>> | testRecvImmediate (unit.ServerTestCase) ... ok
>> | testRecvTimeout (unit.ServerTestCase) ... ok
>> | testSendBlob (unit.ServerTestCase) ... ok
>> | testSendBundle (unit.ServerTestCase) ... ok
>> | testSendInt (unit.ServerTestCase) ... ok
>> | testSendInvalid (unit.ServerTestCase) ... ok
>> | testSendMessage (unit.ServerTestCase) ... ok
>> | testSendOthers (unit.ServerTestCase) ... Bus error (core dumped)
>> | make[1]: *** [test-python2.7] Error 138
>>
>> I was able to reproduce this issue on smetana.d.o. liblo rebuilt with
>> debugging symbols gives me the following back trace:
>>
>> Core was generated by `python2.7 -m unittest discover -s test/ -p *.py -v'.
>> Program terminated with signal 10, Bus error.
>> #0  0x7056634c in lo_arg_network_endian (type=<error reading variable: Cannot access memory at address 0x47>,
>>     data=<error reading variable: Cannot access memory at address 0x4b>) at message.c:687
>> 687             *(int64_t *)data = lo_htoo64(*(int64_t *)data);
>> (gdb) bt
>> #0  0x7056634c in lo_arg_network_endian (type=<error reading variable: Cannot access memory at address 0x47>,
>>     data=<error reading variable: Cannot access memory at address 0x4b>) at message.c:687
>> #1  0x7036c008 in ?? () from /lib/sparc-linux-gnu/libc.so.6
>> #2  0x7036c008 in ?? () from /lib/sparc-linux-gnu/libc.so.6
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> I've debugged this a bit further and it looks like liblo is broken on
> sparc. Using the two binaries shipped in liblo-tools, one can easily
> produce bus errors:
>
> In one shell run 'oscdump 54321', in the other 'oscsend localhost 54321
> /test hTfs 12345 3.14 hello' (this is the example from the oscsend with
> 64 bit instead of 32 bit integers) and oscdump immediately crashes with
> a bus error:
>
> Core was generated by `oscdump 54321'.
> Program terminated with signal 10, Bus error.
> #0  0xf7eed3ec in lo_arg_pp_internal () from /usr/lib/liblo.so.7
> (gdb) bt
> #0  0xf7eed3ec in lo_arg_pp_internal () from /usr/lib/liblo.so.7
> #1  0x0000000d in ?? ()
> #2  0x0000000d in ?? ()
>
> So this makes me believe that liblo is broken on sparc and hence I'm
> reassigning this bug to liblo.
>
> Regards
> --
> Sebastian Ramacher
>
> _______________________________________________
> pkg-multimedia-maintainers mailing list
> pkg...@li...
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers



-- 

Saludos,
Felipe Sateler