[ros-users] Debuggin ROS_COMM deserializer

Claudio Carbone cla_carbone at tiscali.it
Wed Nov 28 17:22:43 UTC 2012


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 <mailto: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 <tel:%2B393809017424>
>     email: Send email
>     <mailto:cla_carbone at tiscali.it>My linkedin profile
>     <http://it.linkedin.com/in/embeddedesign/en>
>
>     My Portfolio
>     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 <mailto: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/b40812a0/attachment-0004.html>
-------------- 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/b40812a0/attachment-0004.gif>
-------------- 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/b40812a0/attachment-0004.png>


More information about the ros-users mailing list