Re: [liblo] Bug#721617: pyliblo: FTBFS on sparc: testSendOthers (unit.ServerTestCase) ... Bus error

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