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