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
My linkedin profile

My Portfolio
My portfolio site

 


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