[ros-users] Debuggin ROS_COMM deserializer

[Brian Gerkey]

I also suspect that it's an endian mismatch, which I mentioned in answer to
this question at ROS Answers:
http://answers.ros.org/question/49136/arm-buffer-overrun-debug-help/

There I suggested changing the endianness of the embedded machine; I've
never done it myself, but I think that ARM processors can usually be
switched between big and little endian.  As Cedric has pointed out, making
roscpp endian-aware would be better, but making all of your machine
little-endian is a pragmatic workaround.

Btw, if your ARM is running big-endian, then that's almost certainly the
problem.  You should run a sample program to determine that machine's
endianness (look around for an example).

    brian.

On Wed, Nov 28, 2012 at 11:39 AM, Cedric Pradalier <
cedric.pradalier at gmail.com> wrote:

> The easiest would be to explicitly serialise the bytes. For instance:
> For writing:
> uint32_t t = value;
> buffer[0] = (unsigned char)t; t = t >> 8;
> buffer[1] = (unsigned char)t; t = t >> 8;
> buffer[2] = (unsigned char)t; t = t >> 8;
> buffer[3] = (unsigned char)t;
>
> For reading:
> uint32_t t = buffer[3]; t = t << 8;
> t = t | buffer[2]; t = t << 8;
> t = t | buffer[1]; t = t << 8;
> t = t | buffer[0];
> value = t;
>
> This would be the C way, but boost probably already provide
> endianness-safe serialization.
>
> Before changing the code, just put some cout/printf after the length
> decoding and check if the length makes sense. And remember that this is
> just my intuition of where the error could come from because there is
> definitely a bug there. It might be completely unrelated to your problem,
> but the symptoms would fit...
>
> Regards
>
>
> On Wed, Nov 28, 2012 at 6:22 PM, Claudio Carbone <cla_carbone at tiscali.it>wrote:
>
>>  Thanks for the hint Cedric.
>>
>> It's the first time I encounter an endianness problem.
>> At this point we are not even sure this is an endianness problem.
>>
>> I filed a ticket to propose a more descriptive error message in case of
>> buffer overrun, as the way it is now it's really useless (just buffer
>> overrun, but no indication of which buffer, what was the dimension, what
>> was the overrun and how was the dimension specified).
>>
>> By the way: how should I modify the snippet you posted to avoid
>> endianness problems?
>> Wouldn't compiling with -mlittle-endian solve such problems? (trying now,
>> but it will take about 8hrs to compile)
>>
>> Claudio
>>
>>
>>
>> On 28/11/12 17:46, Cedric Pradalier wrote:
>>
>> Here it is, in roscpp/src/libros, writeHeader
>>   uint32_t msg_len = len + 4;
>>    boost::shared_array<uint8_t> full_msg(new uint8_t[msg_len]);
>>   memcpy(full_msg.get() + 4, buffer.get(), len);
>>   *((uint32_t*)full_msg.get()) = len;
>>
>>  and onHeaderLengthRead:
>>    uint32_t len = *((uint32_t*)buffer.get());
>>
>>  This type of code might create some trouble when run between x86 and
>> arm cpu. However, I could only track this bit of code in the UDP and
>> service loop, and I only checked that this code was there up to fuerte.
>>
>>  In my experience some time ago, I could listen to packet from a gumstix
>> (cturtle, compressed or raw video) from a x86 laptop (diamondback I think).
>> So this might actually be two different bugs...
>>
>>  Now, for people who wonder why I did not report this earlier:
>> contributing to ros_comm has not been very successful so far on my side, so
>> I just keep track of my patches until someone really needs them... (shared
>> memory and compressed transports out-of-the-box for all topics?)
>>
>>  Regards
>>
>>
>> On Wed, Nov 28, 2012 at 5:14 PM, Claudio Carbone <cla_carbone at tiscali.it>wrote:
>>
>>>  Thank you Cedric,
>>>
>>> I'll wait for your info.
>>>
>>> Regards
>>> --
>>>
>>> *Eng. Claudio Carbone
>>> Embedded Systems Design*
>>>
>>> P.IVA: 11688471009
>>> tel: +393809017424
>>> email: Send email
>>>  <cla_carbone at tiscali.it>[image: My linkedin profile]<http://it.linkedin.com/in/embeddedesign/en>
>>>
>>> My Portfolio
>>> [image: My portfolio site] <http://www.fusioncoredesign.it/>
>>>
>>>
>>>
>>>
>>> On 28/11/12 17:09, Cedric Pradalier wrote:
>>>
>>> Hi,
>>>
>>>  last time I checked, some of the deserialization code was actually
>>> endianness specific (if I'm not mistaken), in particular the length of the
>>> message... This could lead easily to a buffer overrun.
>>>
>>>  I'll try to point out the little bit of code later today.
>>>
>>>  Regards
>>>
>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>>
>>
>>
>>  --
>> Cedric Pradalier
>>
>>
>> _______________________________________________
>> ros-users mailing listros-users at code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
>
> --
> Cedric Pradalier
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121128/a07c611b/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11839 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121128/a07c611b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2321 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121128/a07c611b/attachment-0004.gif>