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 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 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 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 >> [image: My linkedin profile] >> >> My Portfolio >> [image: 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 > > > _______________________________________________ > ros-users mailing listros-users@code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > -- Cedric Pradalier