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@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@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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Cedric Pradalier